rfc9755.original.xml   rfc9755.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.0. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-extra-6855bis-04" number="9755" category="std" consensus="true" submission
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft Type="IETF" xml:lang="en" tocInclude="true" obsoletes="6855" updates="" version=
-ietf-extra-6855bis-04" category="std" consensus="true" submissionType="IETF" xm "3" symRefs="true" sortRefs="true">
l:lang="en" obsoletes="6855" version="3">
<!-- xml2rfc v2v3 conversion 3.24.0 -->
<front> <front>
<title abbrev="UTF8=ACCEPT">IMAP Support for UTF-8</title> <title abbrev="UTF8=ACCEPT">IMAP Support for UTF-8</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-extra-6855bis-04"/> <seriesInfo name="RFC" value="9755"/>
<author initials="P." surname="Resnick" fullname="Pete Resnick"> <author initials="P." surname="Resnick" fullname="Pete Resnick">
<organization>Episteme Technology Consulting LLC</organization> <organization>Episteme Technology Consulting LLC</organization>
<address> <address>
<postal> <postal>
<street>503 West Indiana Avenue</street> <street>503 West Indiana Avenue</street>
<city>Urbana</city> <city>Urbana</city>
<code>IL 61801-4941</code> <region>IL</region> <code>61801-4941</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>resnick@episteme.net</email> <email>resnick@episteme.net</email>
</address> </address>
</author> </author>
<author initials="J." surname="Yao" fullname="Jiankang Yao"> <author initials="J." surname="Yao" fullname="Jiankang Yao">
<organization>CNNIC</organization> <organization>CNNIC</organization>
<address> <address>
<postal> <postal>
<street>No.4 South 4th Zhongguancun Street</street> <street>No.4 South 4th Zhongguancun Street</street>
<city>Beijing</city> <city>Beijing</city>
skipping to change at line 51 skipping to change at line 51
<address> <address>
<postal> <postal>
<street>6 Rond Point Schumann, Bd. 1</street> <street>6 Rond Point Schumann, Bd. 1</street>
<city>Brussels</city> <city>Brussels</city>
<code>1040</code> <code>1040</code>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<email>arnt@gulbrandsen.priv.no</email> <email>arnt@gulbrandsen.priv.no</email>
</address> </address>
</author> </author>
<date year="2024" month="November" day="13"/> <date year="2025" month="February"/>
<area>Applications</area> <area>ART</area>
<workgroup>EXTRA</workgroup> <workgroup>extra</workgroup>
<keyword>IMAP</keyword> <keyword>IMAP</keyword>
<abstract> <abstract><t>This specification extends the Internet Message Access
<?line 64?> Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded intern
ational
<t>This specification extends the Internet Message Access Protocol characters in user names, mail addresses, and message headers. This
(IMAP4rev1, RFC 3501) to support UTF-8 encoded international specification replaces RFC 6855. This specification does not extend
characters in user names, mail addresses, and message headers. This IMAP4rev2 (RFC 9051), since that protocol includes
specification replaces RFC 6855. This specification does not extend everything in this extension.</t>
IMAP4rev2 <xref target="RFC9051"/>, since that protocol includes everything in t
his
extension.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 73?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This specification forms part of the Email Address <t>This specification forms part of the Email Address
Internationalization protocols described in the Email Address Internationalization protocols described in the Email Address
Internationalization Framework document <xref target="RFC6530"/>. It extends IM AP Internationalization Framework document <xref target="RFC6530"/>. It extends IM AP
<xref target="RFC3501"/> to permit UTF-8 <xref target="RFC3629"/> in headers, as described in <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 "Internationalized Email Headers" <xref target="RFC6532"/>. It also adds a
mechanism to support mailbox names using the UTF-8 charset. This mechanism to support mailbox names using the UTF-8 charset. This
specification creates two new IMAP capabilities to allow servers to specification creates two new IMAP capabilities to allow servers to
advertise these new extensions.</t> advertise these new extensions.</t>
<t>This specification assumes that the IMAP server will be operating in <t>This specification assumes that the IMAP server will be operating in
a fully internationalized environment, i.e., one in which all clients a fully internationalized environment, i.e., one in which all clients
accessing the server will be able to accept non-ASCII message header accessing the server will be able to accept non-ASCII message header
fields and other information, as specified in Section 3. At least fields and other information, as specified in <xref target="utf8accept-imap-capa bility-and-utf-8-in-imap-quoted-strings"/>. At least
during a transition period, that assumption will not be realistic for during a transition period, that assumption will not be realistic for
many environments; the issues involved are discussed in Section 7 many environments; the issues involved are discussed in <xref target="utf8only-c apability"/>
below.</t> below.</t>
<t>This specification replaces an earlier, experimental approach to the <t>This specification replaces an earlier, experimental approach to the
same problem <xref target="RFC5738"/> as well as <xref target="RFC6855"/>.</t> same problem; see <xref target="RFC5738"/> as well as <xref target="RFC6855"/>.< /t>
</section> </section>
<section anchor="requirements-language"> <section anchor="requirements-language">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</section> </t>
</section>
<section anchor="utf8accept-imap-capability-and-utf-8-in-imap-quoted-strings "> <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 > <name>"UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings</name >
<t>The "UTF8=ACCEPT" capability indicates that the server supports the <t>The "UTF8=ACCEPT" capability indicates that the server supports the
ability to open mailboxes containing internationalized messages with ability to open mailboxes containing internationalized messages with
the "SELECT" and "EXAMINE" commands, and the server can provide UTF-8 the "SELECT" and "EXAMINE" commands, and the server can provide UTF-8
responses to the "LIST" and "LSUB" commands. This capability also responses to the "LIST" and "LSUB" commands. This capability also
affects other IMAP extensions that can return mailbox names or their affects other IMAP extensions that can return mailbox names or their
prefixes, such as NAMESPACE <xref target="RFC2342"/> and ACL <xref target="RFC43 14"/>.</t> prefixes, such as NAMESPACE <xref target="RFC2342"/> and ACL <xref target="RFC43 14"/>.</t>
<t>The "UTF8=ONLY" capability, described in Section 7, implies the <t>The "UTF8=ONLY" capability, described in <xref target="utf8only-capabil ity"/>, implies the
"UTF8=ACCEPT" capability. A server is said to support "UTF8=ACCEPT" "UTF8=ACCEPT" capability. A server is said to support "UTF8=ACCEPT"
if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY".</t> if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY".</t>
<t>A client <bcp14>MUST</bcp14> use the "ENABLE" command <xref target="RFC 5161"/> with the <t>A client <bcp14>MUST</bcp14> use the "ENABLE" command <xref target="RFC 5161"/> with the
"UTF8=ACCEPT" option (defined in Section 4 below) to indicate to the "UTF8=ACCEPT" option (defined in <xref target="append-command"/> below) to indic ate to the
server that the client accepts UTF-8 in quoted-strings and supports server that the client accepts UTF-8 in quoted-strings and supports
the "UTF8=ACCEPT" extension. The "ENABLE UTF8=ACCEPT" command is the "UTF8=ACCEPT" extension. The "ENABLE UTF8=ACCEPT" command is
only valid in the authenticated state.</t> only valid in the authenticated state.</t>
<t>The IMAP base specification <xref target="RFC3501"/> forbids the use of 8-bit <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 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 be sent as a literal. This can be inconvenient from a coding
standpoint, and unless the server offers IMAP non-synchronizing standpoint, and unless the server offers IMAP non-synchronizing
literals <xref target="RFC2088"/>, this requires an extra round trip for each UT F-8 literals <xref target="RFC2088"/>, this requires an extra round trip for each UT F-8
string sent by the client. When the IMAP server supports string sent by the client. When the IMAP server supports
"UTF8=ACCEPT", it supports UTF-8 in quoted-strings with the following "UTF8=ACCEPT", it supports UTF-8 in quoted-strings with the following ABNF
syntax:</t> syntax <xref target="RFC5234"/>:</t>
<t>quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE
; QUOTED-CHAR is not modified, as it will affect <sourcecode type="abnf"><![CDATA[
; other RFC 3501 ABNF non-terminals.</t> quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE
<t>uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4</t> ; QUOTED-CHAR is not modified, as it will affect
<t>UTF8-2 = &lt;Defined in Section 4 of RFC 3629&gt;</t> ; other RFC 3501 ABNF non-terminals.
<t>UTF8-3 = &lt;Defined in Section 4 of RFC 3629&gt;</t>
<t>UTF8-4 = &lt;Defined in Section 4 of RFC 3629&gt;</t> uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of RFC 3629>
UTF8-3 = <Defined in Section 4 of RFC 3629>
UTF8-4 = <Defined in Section 4 of RFC 3629>
]]></sourcecode>
<t>When this extended quoting mechanism is used by the client, the <t>When this extended quoting mechanism is used by the client, the
server <bcp14>MUST</bcp14> reject, with a "BAD" response, any octet sequences wi th server <bcp14>MUST</bcp14> reject, with a "BAD" response, any octet sequences wi th
the high bit set that fail to comply with the formal syntax 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 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 in quoted-strings to the client unless the client has indicated
support for that syntax by using the "ENABLE UTF8=ACCEPT" command.</t> 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 <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 quoted syntax with any IMAP argument that permits a string (including
astring and nstring). However, if characters outside the US-ASCII astring and nstring). However, if characters outside the US-ASCII
repertoire are used in an inappropriate place, the results would be repertoire are used in an inappropriate place, the results would be
the same as if other syntactically valid but semantically invalid the same as if other syntactically valid but semantically invalid
characters were used. Specific cases where UTF-8 characters are characters were used. Specific cases where UTF-8 characters are
permitted or not permitted are described in the following paragraphs.</t> permitted or not permitted are described in the following paragraphs.</t>
<!--[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" 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> accep t UTF-8 in <t>All IMAP servers that support "UTF8=ACCEPT" <bcp14>SHOULD</bcp14> accep t UTF-8 in
mailbox names, and those that also support the Mailbox International mailbox names, and those that also support the Mailbox International
Naming Convention described in RFC 3501, Section 5.1.3, <bcp14>MUST</bcp14> acce pt Naming Convention described in <xref section="5.1.3" sectionFormat="comma" targe t="RFC3501"/>, <bcp14>MUST</bcp14> accept
UTF8-quoted mailbox names and convert them to the appropriate UTF8-quoted mailbox names and convert them to the appropriate
internal format. Mailbox names <bcp14>MUST</bcp14> comply with the Net-Unicode internal format. Mailbox names <bcp14>MUST</bcp14> comply with the Net-Unicode
Definition (<xref target="RFC5198"/>, Section 2) with the specific exception tha Definition (<xref section="2" sectionFormat="comma" target="RFC5198"/>) with the
t specific exception that
they <bcp14>MUST NOT</bcp14> contain control characters (U+0000-U+001F and U+008 they <bcp14>MUST NOT</bcp14> contain control characters (U+0000 - U+001F and U+0
0-U+ 080 - U+009F), a delete character (U+007F), a line separator (U+2028), or a
009F), a delete character (U+007F), a line separator (U+2028), or a
paragraph separator (U+2029).</t> 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 <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 UTF8=ACCEPT" command, it <bcp14>MUST NOT</bcp14> issue a "SEARCH" command that
contains a charset specification. If an IMAP server receives such a contains a charset specification. If an IMAP server receives such a
"SEARCH" command in that situation, it <bcp14>SHOULD</bcp14> reject the command with "SEARCH" command in that situation, it <bcp14>SHOULD</bcp14> reject the command with
a "BAD" response (due to the conflicting charset labels).</t> a "BAD" response (due to the conflicting charset labels).</t>
</section> </section>
<section anchor="append-command"> <section anchor="append-command">
<name>"APPEND" Command</name> <name>"APPEND" Command</name>
<t>If the server supports "UTF8=ACCEPT", then the server accepts UTF-8 <t>If the server supports "UTF8=ACCEPT", then the server accepts UTF-8
headers in the "APPEND" command message argument.</t> headers in the "APPEND" command message argument.</t>
skipping to change at line 183 skipping to change at line 210
credentials.</t> credentials.</t>
<t>Although using the IMAP "AUTHENTICATE" command in this way makes it <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 syntactically legal to have a UTF-8 username or password, there is no
guarantee that the user provisioning system utilized by the IMAP guarantee that the user provisioning system utilized by the IMAP
server will allow such identities. This is an implementation server will allow such identities. This is an implementation
decision and may depend on what identity system the IMAP server is decision and may depend on what identity system the IMAP server is
configured to use.</t> configured to use.</t>
</section> </section>
<section anchor="fetch-bodystructure-and-messageglobal"> <section anchor="fetch-bodystructure-and-messageglobal">
<name>FETCH BODYSTRUCTURE and message/global</name> <name>FETCH BODYSTRUCTURE and message/global</name>
<t><xref target="RFC9051"/> section 7.5.2 treats message/global like messa ge/rfc, <t><xref section="7.5.2" sectionFormat="comma" target="RFC9051"/> treats m essage/global like message/rfc,
which means that for some messages, the response to FETCH which means that for some messages, the response to FETCH
BODYSTRUCTURE varies depending on whether IMAP4rev1 or IMAP4rev2 is BODYSTRUCTURE varies depending on whether IMAP4rev1 or IMAP4rev2 is
in use.</t> in use.</t>
<t><xref target="RFC6855"/> does not extend <xref target="RFC3501"/> in th is respect. This document <t><xref target="RFC6855"/> does not extend <xref target="RFC3501"/> in th is respect. This document
extends the media-message ABNF production to match <xref target="RFC9051"/>.</t> extends the media-message ABNF production to match <xref target="RFC9051"/>.</t>
<t>media-message = DQUOTE "MESSAGE" DQUOTE SP
DQUOTE ("RFC822" / "GLOBAL") DQUOTE</t> <sourcecode type="abnf"><![CDATA[
media-message = DQUOTE "MESSAGE" DQUOTE SP
DQUOTE ("RFC822" / "GLOBAL") DQUOTE
]]></sourcecode>
<t>When IMAP4rev1 and UTF8=ACCEPT has been enabled, the server <bcp14>MAY< /bcp14> treat <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, message/global like message/rfc822 when computing the body structure,
but <bcp14>MAY</bcp14> also treat it as described in <xref target="RFC3501"/>. C lients <bcp14>MUST</bcp14> accept but <bcp14>MAY</bcp14> also treat it as described in <xref target="RFC3501"/>. C lients <bcp14>MUST</bcp14> accept
both cases.</t> both cases.</t>
<t>When IMAP4rev2 and UTF8=ACCEPT are in use, the server <bcp14>MUST</bcp1 4> behave as <t>When IMAP4rev2 and UTF8=ACCEPT are in use, the server <bcp14>MUST</bcp1 4> behave as
described in <xref target="RFC9051"/>.</t> described in <xref target="RFC9051"/>.</t>
</section> </section>
<section anchor="utf8only-capability"> <section anchor="utf8only-capability">
<name>"UTF8=ONLY" Capability</name> <name>"UTF8=ONLY" Capability</name>
<t>The "UTF8=ONLY" capability indicates that the server supports <t>The "UTF8=ONLY" capability indicates that the server supports
"UTF8=ACCEPT" (see Section 3) and that it requires support for UTF-8 "UTF8=ACCEPT" (see <xref target="utf8accept-imap-capability-and-utf-8-in-imap-qu oted-strings"/>) and that it requires support for UTF-8
from clients. In particular, this means that the server will send from clients. In particular, this means that the server will send
UTF-8 in quoted-strings, and it will not accept the older UTF-8 in quoted-strings, and it will not accept the older
international mailbox name convention (modified UTF-7 <xref target="RFC3501"/>). international mailbox name convention (modified UTF-7 <xref target="RFC3501"/>).
Because these are incompatible changes to IMAP, explicit server Because these are incompatible changes to IMAP, explicit server
announcement and client confirmation is necessary: clients <bcp14>MUST</bcp14> u se announcement and client confirmation are necessary: clients <bcp14>MUST</bcp14> use
the "ENABLE UTF8=ACCEPT" command before using this server. A server the "ENABLE UTF8=ACCEPT" command before using this server. A server
that advertises "UTF8=ONLY" will reject, with a "NO [CANNOT]" that advertises "UTF8=ONLY" will reject, with a "NO [CANNOT]"
response <xref target="RFC5530"/>, any command that might require UTF-8 support and response <xref target="RFC5530"/>, any command that might require UTF-8 support and
is not preceded by an "ENABLE UTF8=ACCEPT" command.</t> is not preceded by an "ENABLE UTF8=ACCEPT" command.</t>
<t>IMAP clients that find support for a server that announces <t>IMAP clients that find support for a server that announces
"UTF8=ONLY" problematic are encouraged to at least detect the "UTF8=ONLY" problematic are encouraged to at least detect the
announcement and provide an informative error message to the announcement and provide an informative error message to the
end-user.</t> end user.</t>
<t>Because the "UTF8=ONLY" server capability includes support for <t>Because the "UTF8=ONLY" server capability includes support for
"UTF8=ACCEPT", the capability string will include, at most, one of "UTF8=ACCEPT", the capability string will include, at most, one of
those and never both. For the client, "ENABLE UTF8=ACCEPT" is always those and never both. For the client, "ENABLE UTF8=ACCEPT" is always
used -- never "ENABLE UTF8=ONLY".</t> used -- never "ENABLE UTF8=ONLY".</t>
</section> </section>
<section anchor="dealing-with-legacy-clients"> <section anchor="dealing-with-legacy-clients">
<name>Dealing with Legacy Clients</name> <name>Dealing with Legacy Clients</name>
<t>In most situations, it will be difficult or impossible for the <t>In most situations, it will be difficult or impossible for the
implementer or operator of an IMAP (or POP) server to know whether 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 all of the clients that might access it, or the associated mail store
skipping to change at line 255 skipping to change at line 286
(including IMAP clients) or not provide expected information to (including IMAP clients) or not provide expected information to
users. There are also trade-offs in constructing surrogates of the users. There are also trade-offs in constructing surrogates of the
original message between accepting complexity and additional original message between accepting complexity and additional
computation costs in order to try to preserve as much information as computation costs in order to try to preserve as much information as
possible (for example, in "Post-Delivery Message Downgrading for possible (for example, in "Post-Delivery Message Downgrading for
Internationalized Email Messages" <xref target="RFC6857"/>) and trying to minimi ze Internationalized Email Messages" <xref target="RFC6857"/>) and trying to minimi ze
those costs while still providing useful information (for example, in those costs while still providing useful information (for example, in
"Simplified POP and IMAP Downgrading for Internationalized Email" "Simplified POP and IMAP Downgrading for Internationalized Email"
<xref target="RFC6858"/>).</t> <xref target="RFC6858"/>).</t>
<t>Implementations that choose to perform downgrading <bcp14>SHOULD</bcp14 > use one of <t>Implementations that choose to perform downgrading <bcp14>SHOULD</bcp14 > use one of
the standardized algorithms provided in RFC 6857 or RFC 6858. the standardized algorithms provided in <xref target="RFC6857"/> or <xref target ="RFC6858"/>.
Getting downgrade algorithms right, and minimizing the risk of Getting downgrade algorithms right, and minimizing the risk of
operational problems and harm to the email system, is tricky and operational problems and harm to the email system, is tricky and
requires careful engineering. These two algorithms are well requires careful engineering. These two algorithms are well
understood and carefully designed.</t> understood and carefully designed.</t>
<t>Because such messages are really surrogates of the original ones, not <t>Because such messages are really surrogates of the original ones, not
really "downgraded" ones (although that terminology is often used for really "downgraded" ones (although that terminology is often used for
convenience), they inevitably have relationships to the originals convenience), they inevitably have relationships to the originals
that the IMAP specification <xref target="RFC3501"/> did not anticipate. This that the IMAP specification <xref target="RFC3501"/> did not anticipate. This
brings up two concerns in particular: First, digital signatures brings up two concerns in particular: First, digital signatures
computed over and intended for the original message will often not be computed over and intended for the original message will often not be
skipping to change at line 300 skipping to change at line 331
</section> </section>
<section anchor="issues-with-utf-8-header-mailstore"> <section anchor="issues-with-utf-8-header-mailstore">
<name>Issues with UTF-8 Header Mailstore</name> <name>Issues with UTF-8 Header Mailstore</name>
<t>When an IMAP server uses a mailbox format that supports UTF-8 headers <t>When an IMAP server uses a mailbox format that supports UTF-8 headers
and it permits selection or examination of that mailbox without and it permits selection or examination of that mailbox without
issuing "ENABLE UTF8=ACCEPT" first, it is the responsibility of the issuing "ENABLE UTF8=ACCEPT" first, it is the responsibility of the
server to comply with the IMAP base specification <xref target="RFC3501"/> and t he server to comply with the IMAP base specification <xref target="RFC3501"/> and t he
Internet Message Format <xref target="RFC5322"/> with respect to all header Internet Message Format <xref target="RFC5322"/> with respect to all header
information transmitted over the wire. The issue of handling information transmitted over the wire. The issue of handling
messages containing non-ASCII characters in legacy environments is messages containing non-ASCII characters in legacy environments is
discussed in Section 8.</t> discussed in <xref target="dealing-with-legacy-clients"/>.</t>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>the "IMAP 4 Capabilities" registry contains a number of references to <t>the "IMAP Capabilities" registry contained a number of references to
RFC6855. IANA, please change them to point to this document instead of <xref target="RFC6855"/>. IANA has updated them point to this document instead.
RFC6855. The affected references are:</t> The affected references are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>UTF8=ACCEPT</t> <t>UTF8=ACCEPT</t>
</li> </li>
<li> <li>
<t>UTF8=ALL (OBSOLETE)</t> <t>UTF8=ALL (OBSOLETE)</t>
</li> </li>
<li> <li>
<t>UTF8=APPEND (OBSOLETE)</t> <t>UTF8=APPEND (OBSOLETE)</t>
</li> </li>
skipping to change at line 336 skipping to change at line 366
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations of UTF-8 <xref target="RFC3629"/> and SASLp rep <t>The security considerations of UTF-8 <xref target="RFC3629"/> and SASLp rep
<xref target="RFC4013"/> apply to this specification, particularly with respect to <xref target="RFC4013"/> apply to this specification, particularly with respect to
use of UTF-8 in usernames and passwords. Otherwise, this is not use of UTF-8 in usernames and passwords. Otherwise, this is not
believed to alter the security considerations of IMAP.</t> believed to alter the security considerations of IMAP.</t>
<t>Special considerations, some of them with security implications, occur <t>Special considerations, some of them with security implications, occur
if a server that conforms to this specification is accessed by a 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 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 which a given message is accessed by multiple clients that might use
different protocols and/or support different capabilities. Those different protocols and/or support different capabilities. Those
issues are discussed in Section 8.</t> issues are discussed in <xref target="dealing-with-legacy-clients"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
le> 501.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<date month="March" year="1997"/> 629.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<t>In many standards track documents several words are used to sig 013.xml"/>
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
his document defines these words as they should be interpreted in IETF documents 161.xml"/>
. This document specifies an Internet Best Current Practices for the Internet Co <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
mmunity, and requests discussion and suggestions for improvements.</t> 198.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</front> 234.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<seriesInfo name="RFC" value="2119"/> 322.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</reference> 530.xml"/>
<reference anchor="RFC3501"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 532.xml"/>
<title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="M. Crispin" initials="M." surname="Crispin"/> 174.xml"/>
<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 th
at is functionally equivalent to local folders. IMAP4rev1 also provides the capa
bility for an offline client to resynchronize with the server. IMAP4rev1 include
s operations for creating, deleting, and renaming mailboxes, checking for new me
ssages, 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. IMAP4
rev1 supports a single server. A mechanism for accessing configuration informati
on to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 doe
s not specify a means of posting mail; this function is handled by a mail transf
er 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 Univer
sal Character Set (UCS) which encompasses most of the world's writing systems. T
he originally proposed encodings of the UCS, however, were not compatible with m
any current applications and protocols, and this has led to the development of U
TF-8, the object of this memo. UTF-8 has the characteristic of preserving the fu
ll 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</ti
tle>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga"/>
<date month="February" year="2005"/>
<abstract>
<t>This document describes how to prepare Unicode strings represen
ting user names and passwords for comparison. The document defines the "SASLprep
" profile of the "stringprep" algorithm to be used for both user names and passw
ords. 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 ot
her 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" surnam
e="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 an
d the server supports it. However, a few extensions require the server to know w
hether a client supports that extension. The ENABLE extension allows an IMAP cli
ent 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 tr
ansmission of internationalized "text" information, paralleling the specificatio
ns for the use of ASCII that date from the early days of the ARPANET. This docum
ent specifies that format, using UTF-8 with normalization and specific line-endi
ng 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="R
esnick"/>
<date month="October" year="2008"/>
<abstract>
<t>This document specifies the Internet Message Format (IMF), a sy
ntax for text messages that are sent between computer users, within the framewor
k of "electronic mail" messages. This specification is a revision of Request For
Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "S
tandard for the Format of ARPA Internet Text Messages", updating it to reflect c
urrent practice and incorporating incremental changes that were specified in oth
er 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 o
wn names (written correctly in their own languages and scripts) as mailbox names
in email addresses. This document introduces a series of specifications that de
fine mechanisms and protocol extensions needed to fully support internationalize
d email addresses. These changes include an SMTP extension and extension of emai
l header syntax to accommodate UTF-8 data. The document set also includes discus
sion of key assumptions and issues in deploying fully internationalized email. T
his document is a replacement for RFC 4952; it reflects additional issues identi
fied 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 f
ield values. However, full internationalization of electronic mail requires addi
tional enhancements to allow the use of Unicode, including characters outside th
e 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 comple
x encoded-word constructs. This document specifies an enhancement to the Interne
t Message Format and to MIME that allows use of Unicode in mail addresses and mo
st 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</ti
tle>
<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 protoco
l 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>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC2088"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 088.xml"/>
<title>IMAP4 non-synchronizing literals</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="J. Myers" initials="J." surname="Myers"/> 342.xml"/>
<date month="January" year="1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<abstract> 314.xml"/>
<t>The Internet Message Access Protocol [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</abstract> 530.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<seriesInfo name="RFC" value="2088"/> 738.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2088"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</reference> 855.xml"/>
<reference anchor="RFC2342"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 857.xml"/>
<title>IMAP4 Namespace</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="M. Gahrns" initials="M." surname="Gahrns"/> 858.xml"/>
<author fullname="C. Newman" initials="C." surname="Newman"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="May" year="1998"/> 620.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>This document defines a NAMESPACE command that allows a client 051.xml"/>
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 Inter
net Message Access Protocol (IMAP) permits mailbox access control lists to be re
trieved 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 IMA
P 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 opt
ional machine-readable response code, and a human-readable text.</t>
<t>This document collects and documents a variety of machine-reada
ble response codes, for better interoperation and error reporting. [STANDARDS-TR
ACK]</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 Experi
mental 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="R
esnick"/>
<author fullname="C. Newman" initials="C." role="editor" surname="Ne
wman"/>
<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 ad
dresses, 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 Internationaliz
ation, a POP or IMAP server cannot deliver internationalized messages to the cli
ent and cannot remove the message. To avoid that situation, this document descri
bes a mechanism for converting internationalized messages into the traditional m
essage format. As part of the conversion process, message elements that require
internationalized treatment are recoded or removed, and receivers are able to re
cognize that they received messages containing such elements, even if they canno
t 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 Ema
il</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 se
rve internationalized messages to conventional clients. The specification is sim
ple, 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 q
uery, fetch, and modify JSON-based data objects, with support for push notificat
ion of changes and fast resynchronisation and for out-of- band binary data uploa
d/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</titl
e>
<author fullname="A. Melnikov" initials="A." role="editor" surname="
Melnikov"/>
<author fullname="B. Leiba" initials="B." role="editor" surname="Lei
ba"/>
<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. I
MAP4rev2 permits manipulation of mailboxes (remote message folders) in a way tha
t is functionally equivalent to local folders. IMAP4rev2 also provides the capab
ility for an offline client to resynchronize with the server.</t>
<t>IMAP4rev2 includes operations for creating, deleting, and renam
ing mailboxes; checking for new messages; removing messages permanently; setting
and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selec
tive fetching of message attributes, texts, and portions thereof. Messages in IM
AP4rev2 are accessed by the use of numbers. These numbers are either message seq
uence numbers or unique identifiers.</t>
<t>IMAP4rev2 does not specify a means of posting mail; this functi
on is handled by a mail submission protocol such as the one specified in RFC 640
9.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9051"/>
<seriesInfo name="DOI" value="10.17487/RFC9051"/>
</reference>
</references> </references>
</references> </references>
<?line 372?>
<section anchor="design-rationale"> <section anchor="design-rationale">
<name>Design Rationale</name> <name>Design Rationale</name>
<t>This non-normative section discusses the reasons behind some of the <t>This non-normative section discusses the reasons behind some of the
design choices in this specification.</t> design choices in this specification.</t>
<t>The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability <t>The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability
problems when legacy support goes away. In the situation where problems when legacy support goes away. In the situation where
backwards compatibility is not working anyway, the non-conforming backwards compatibility is not working anyway, the non-conforming
"just-send-UTF-8 IMAP" has the advantage that it might work with some "just-send-UTF-8 IMAP" has the advantage that it might work with some
legacy clients. However, the difficulty of diagnosing legacy clients. However, the difficulty of diagnosing
interoperability problems caused by a "just-send-UTF-8 IMAP" mechanism interoperability problems caused by a "just-send-UTF-8 IMAP" mechanism
is the reason the "UTF8=ONLY" capability mechanism was chosen.</t> is the reason the "UTF8=ONLY" capability mechanism was chosen.</t>
</section> </section>
<section anchor="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>
<section anchor="changes-since-rfc-6855"> <section anchor="changes-since-rfc-6855">
<name>Changes since RFC 6855</name> <name>Changes since RFC 6855</name>
<t>This non-normative section describes the changes made since <t>This non-normative section describes the changes made since
<xref target="RFC6855"/>.</t> <xref target="RFC6855"/>.</t>
<section anchor="append-utf8"> <section anchor="append-utf8">
<name>APPEND UTF8</name> <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-relate d <t>This document removes APPEND's UTF8 data item, making the UTF8-relate d
syntax compatible with IMAP4rev2 as defined by <xref target="RFC9051"/> and maki ng syntax compatible with IMAP4rev2 as defined by <xref target="RFC9051"/> and maki ng
it simpler for clients to support IMAP4rev1 and IMAP4rev2 with the it simpler for clients to support IMAP4rev1 and IMAP4rev2 with the
same code.</t> same code.</t>
<t>IMAP4rev2 <xref target="RFC9051"/> provides roughly the same abilitie s as <t>IMAP4rev2 <xref target="RFC9051"/> provides roughly the same abilitie s as
<xref target="RFC6855"/> but does not include APPEND's UTF8 item. None of <xref target="RFC6855"/> but does not include APPEND's UTF8 item. None of
<xref target="RFC6855"/>, IMAP4rev2 or JMAP <xref target="RFC8620"/> specify any way to learn <xref target="RFC6855"/>, IMAP4rev2, or JMAP <xref target="RFC8620"/> specify an y way to learn
whether a particular message was stored using the UTF8 data item. As whether a particular message was stored using the UTF8 data item. As
of today, an IMAP client cannot learn whether a particular message was 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 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 even if IMAP4rev1/2 were extended to provide that
information.</t> 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 <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 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 data item for all messages if the server supports UTF8=ACCEPT, without
regard to whether a particular message includes any UTF8 at all).</t> 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 <t>For these reasons, it was judged best to revise <xref target="RFC6855 "/> and adopt
the same syntax as IMAP4rev2.</t> the same syntax as IMAP4rev2.</t>
</section> </section>
<section anchor="fetch-bodystructure"> <section anchor="fetch-bodystructure">
<name>FETCH BODYSTRUCTURE</name> <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, whi ch is <t><xref target="RFC6532"/> defines a new MIME type, message/global, whi ch is
substantially like message/rfc822 except that the submessage may substantially like message/rfc822 except that the submessage may
(also) use the syntax defined in <xref target="RFC6532"/>. <xref target="RFC3501 "/> and (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 <xref target="RFC9051"/> define a FETCH item to return the MIME structure of a
message, which servers usually compute once and store.</t> message, which servers usually compute once and store.</t>
<t>None of the RFCs point out to implementers that IMAP4rev1 and <t>None of the RFCs point out to implementers that IMAP4rev1 and
IMAP4rev2 are slighly different, so storing the BODYSTRUCTURE in the IMAP4rev2 are slightly different, so storing the BODYSTRUCTURE in the
way servers and clients often do can easily lead to problems.</t> way servers and clients often do can easily lead to problems.</t>
<t>This document makes the syntax optional, making it simple for server <t>This document makes the syntax optional, making it simple for server
authors to implement this extension correctly. This implies that authors to implement this extension correctly. This implies that
clients need to parse and handle both varieties, which they need to do clients need to parse and handle both varieties, which they need to do
anyway if they want to support both IMAP4rev1 and IMAP4rev2.</t> anyway if they want to support both IMAP4rev1 and IMAP4rev2.</t>
</section> </section>
</section> </section>
</back>
<!-- ##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=
<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
--> -->
<!-- [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> </rfc>
 End of changes. 39 change blocks. 
637 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.48.