rfc9698.original.xml   rfc9698.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- draft submitted in xml v3 -->
<!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.6 (Ruby 3.0.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-extra-jmapaccess-09" number="9698" tocInclude="true" updates="" obsoletes=
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft "" category="std" consensus="true" submissionType="IETF" sortRefs="true" xml:lan
-ietf-extra-jmapaccess-08" category="std" consensus="true" submissionType="IETF" g="en" version="3">
xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.20.0 -->
<front> <front>
<title abbrev="IMAP JMAPACCESS">The JMAPACCESS Extension for IMAP</title> <title abbrev="IMAP JMAPACCESS">The JMAPACCESS Extension for IMAP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-extra-jmapaccess-08"/> <seriesInfo name="RFC" value="9698"/>
<author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen"> <author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen">
<organization>ICANN</organization> <organization>ICANN</organization>
<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>
skipping to change at line 41 skipping to change at line 43
<postal> <postal>
<street>Level 2, 114 William St.</street> <street>Level 2, 114 William St.</street>
<city>Melbourne VIC</city> <city>Melbourne VIC</city>
<code>3000</code> <code>3000</code>
<country>Australia</country> <country>Australia</country>
</postal> </postal>
<email>brong@fastmailteam.com</email> <email>brong@fastmailteam.com</email>
<uri>https://fastmail.com</uri> <uri>https://fastmail.com</uri>
</address> </address>
</author> </author>
<date year="2024" month="March" day="01"/> <date year="2024" month="December"/>
<area>Applications</area>
<workgroup>EXTRA</workgroup> <area>ART</area>
<workgroup>extra</workgroup>
<keyword>IMAP</keyword> <keyword>IMAP</keyword>
<keyword>JMAP</keyword> <keyword>JMAP</keyword>
<abstract> <abstract>
<?line 51?>
<t>This document defines an IMAP extension to let clients know that the <t>This document defines an IMAP extension to let clients know that the
messages in this IMAP server are also available via JMAP, and how. It is messages in this IMAP server are also available via the JSON Meta Application Pr otocol (JMAP), and how. It is
intended for clients that want to migrate gradually to JMAP or use intended for clients that want to migrate gradually to JMAP or use
JMAP extensions within an IMAP client.</t> JMAP extensions within an IMAP client.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 58?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>An IMAP server can declare that the messages in its mailstore are also <t>An IMAP server can declare that the messages in its mailstore are also
available via JMAP. For simplicity, only a complete equivalence is available via JMAP. For simplicity, only a complete equivalence is
supported (the same set of messages are available via both IMAP and supported (the same set of messages are available via both IMAP and
JMAP).</t> JMAP).</t>
<t>This document also defines a way to provide debugging information that
can be forwarded to client developers without privacy concerns, which
is used by JMAPACCESS but can also be used by others.</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.
</t>
</section> </section>
<section anchor="details"> <section anchor="details">
<name>Details</name> <name>Details</name>
<t>By advertising the JMAPACCESS capability, the server asserts that if a <t>By advertising the JMAPACCESS capability, the server asserts that if a
mailbox or message has a particular object ID when accessed via either mailbox or message has a particular object ID when accessed via either
IMAP or JMAP (see <xref target="RFC3501"/>, <xref target="RFC9051"/> and <xref t arget="RFC8620"/>), then the IMAP or JMAP (see <xref target="RFC3501"/>, <xref target="RFC9051"/>, and <xref target="RFC8620"/>), then the
same mailbox or message is accessible via the other protocol, and it same mailbox or message is accessible via the other protocol, and it
has the same ID.</t> has the same ID.</t>
<t>The server <bcp14>MUST</bcp14> also advertise the OBJECTID extension, d efined by <t>The server <bcp14>MUST</bcp14> also advertise the OBJECTID extension, d efined by
<xref target="RFC8474"/>. The JMAP session resource that allows access to the sa me <xref target="RFC8474"/>. The JMAP session resource that allows access to the sa me
messages is called "the JMAP server" below.</t> messages is called "the JMAP server" below.</t>
<t>This specification does not affect message lifetime: If a client <t>This specification does not affect message lifetime: If a client
accesses a message via IMAP and half a second later via JMAP, then the accesses a message via IMAP and half a second later via JMAP, then the
message may have been deleted between the two accesses.</t> message may have been deleted between the two accesses.</t>
<t>When the server processes the client's LOGIN/AUTHENTICATE command and <t>When the server processes the client's LOGIN/AUTHENTICATE command and
enters Authenticated state, the server considers the way the client enters Authenticated state, the server considers the way the client
authenticated. If the IMAP server can infer from the client's authenticated. If the IMAP server can infer from the client's
authentication process that its credentials suffice to authenticate authentication process that its credentials suffice to authenticate
via JMAP, then the server <bcp14>MUST</bcp14> also send a JMAPACCESS response co via JMAP, then the server <bcp14>MUST</bcp14> include a JMAPACCESS capability in
de any
containing a link to the JMAP server.</t> capability list sent after that point. This includes the capability
list that some servers send immediately when authentication succeeds.</t>
<t>Servers are encouraged to report the same message flags and other data <t>Servers are encouraged to report the same message flags and other data
via both protocols, as far as possible.</t> via both protocols, as far as possible.</t>
<t>This specification does not require mailboxes to have the same name in <t>This specification does not require mailboxes to have the same name in
IMAP and JMAP, even if they share mailbox ID. However, the JMAP IMAP and JMAP, even if they share a mailbox ID. However, the JMAP
specification regulates that, in the text about the name and role specification regulates that in the text about the name and role
properties in <xref target="RFC8620"/> section 2.</t> properties described in <xref target="RFC8620" sectionFormat="of" section="2"/>.
</t>
<t>Note that all JMAP servers support internationalized email addresses <t>Note that all JMAP servers support internationalized email addresses
(see <xref target="RFC6530"/>). If this IMAP server does not, or the IMAP clien (see <xref target="RFC6530"/>). If this IMAP server does not or if the IMAP cli
t ent
does not issue ENABLE UTF8=ACCEPT (see <xref target="RFC6855"/>), then there is does not issue ENABLE UTF8=ACCEPT (see <xref target="RFC6855"/>), then it is pos
a sible
possibility that the client receives accurate address fields via JMAP that the client will receive accurate address fields via JMAP
and downgraded fields via IMAP (see (see <xref target="RFC6857"/> and <xref targ and downgraded fields via IMAP (see <xref target="RFC6857"/> and <xref target="R
et="RFC6858"/> FC6858"/>
for examples). Issuing ENABLE UTF8=ACCEPT is a simple way to sidestep for examples). Issuing ENABLE UTF8=ACCEPT is a simple way to sidestep
the issue.</t> the issue.</t>
</section> </section>
<section anchor="the-jmapaccess-response-code"> <section anchor="the-jmapaccess-response-code">
<name>The JMAPACCESS Response Code</name> <name>The GETJMAPACCESS Command and the JMAPACCESS Response</name>
<t>The JMAPACCESS response code is followed by a single link to a JMAP <t>
session resource. The server/mailstore at that location is referenced The GETJMAPACCESS command requests that the server respond with the
as "the JMAP server" in this document.</t> session URL for the JMAP server that provides access to the same
<t>The formal syntax in <xref target="RFC9051"/> is extended thus:</t> mail.</t>
<t>resp-code-jmapaccess = "JMAPACCESS" SP quoted</t>
<t>resp-text-code =/ resp-code-jmapaccess</t> <t> If such a JMAP server is known to this server, the server <bcp14>MUST</bcp
14>
respond with an untagged JMAPACCESS response containing the JMAP
server's session resource (a URL) followed by a tagged OK response.</t>
<t> If such a JMAP server is not known, the server <bcp14>MUST</bcp14> respond
with a
tagged BAD response (and <bcp14>MUST NOT</bcp14> include JMAPACCESS in the
capability list).</t>
<t> The JMAPACCESS response is followed by a single link to a JMAP
session resource.</t>
<t>The formal syntax in <xref target="RFC9051"/> is extended as follows:</
t>
<sourcecode type="abnf">
command-auth =/ "GETJMAPACCESS"
mailbox-data =/ resp-jmapaccess
resp-jmapaccess = "JMAPACCESS" SP quoted
</sourcecode>
<t>The syntax in <xref target="RFC3501"/> is extended similarly (this exte nsion may be <t>The syntax in <xref target="RFC3501"/> is extended similarly (this exte nsion may be
used with IMAP4rev1 as well as IMAP4rev2).</t> used with IMAP4rev1 as well as IMAP4rev2).</t>
<t>Note that some clients parse response codes from the outside,
ie. scanning for the following ']' before they parse the contents of
the response code. Sending a URL that contains either '"' or ']' may
be risky.</t>
</section> </section>
<section anchor="Examples"> <section anchor="Examples">
<name>Examples</name> <name>Examples</name>
<t>Lines sent by the client are preceded by C:, lines sent by the server <t>Lines sent by the client are preceded by C: and lines sent by the serve
by S:. Each example starts with the IMAP banner issued by the server r are preceded by S:. Each example starts with the IMAP banner issued by the ser
ver
on connection, and generally abbreviates the capability lists to on connection, and generally abbreviates the capability lists to
what's required by the example itself.</t> what's required by the example itself.</t>
<t>Real connections use longer capability lists, much longer AUTHENTICATE <t>Real connections use longer capability lists, much longer AUTHENTICATE
arguments and of course use TLS. These examples focus on JMAPACCESS, arguments and of course use TLS. However, these examples focus on JMAPACCESS.</t
though.</t> >
<t>Example 1. A client connects, sees that SASL OAUTH is available, and
<t>Example 1:</t> <t>A client connects, sees that SASL OAuth <xref target="RFC76
28"/> is available, and
authenticates in that way.</t> authenticates in that way.</t>
<t>S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1<br/>
C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB</t> <sourcecode type="">
S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1
C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB
</sourcecode>
<t>The server processes the command successfully. It knows that the <t>The server processes the command successfully. It knows that the
client used Oauth, and that it and its JMAP alter ego use the same client used OAuth, and that it and its JMAP alter ego use the same
Oauth backend subsystem. Because of that it infers that the (next) OAuth backend subsystem. Because of that it infers that the (next)
access token is just as usable via JMAP as via IMAP. It issues a access token is just as usable via JMAP as via IMAP. It includes a
JMAPACCESS response code in its reply:</t> JMAPACCESS capability in its reply (again, real capability lists are much longer
<t>S: 1 OK [JMAPACCESS "https://example.com/jmap"] done</t> ):
<t>SASL OAUTH is specified by <xref target="RFC7628"/>, and the argument i </t>
n this
example is abbreviated from the more realistic length used in RFC7628.</t> <sourcecode type="">
<t>Example 2. A client connects, sees no SASL method it recognises, and S: 1 OK [CAPABILITY IMAP4rev1 JMAPACCESS] done
C: 1b GETJMAPACCESS
S: * JMAPACCESS "https://example.com/jmap"
S: 1b OK done
</sourcecode>
<t>SASL OAuth is specified by <xref target="RFC7628"/>, and the argument i
n this
example is abbreviated from the more realistic length used in RFC 7628.</t>
<t>Example 2:</t> <t>A client connects, sees no SASL method it recognizes,
and
issues a LOGIN command.</t> issues a LOGIN command.</t>
<t>S: * OK [CAPABILITY IMAP4rev2] example2<br/>
C: 2 LOGIN "arnt" "trondheim"</t> <sourcecode type="">
S: * OK [CAPABILITY IMAP4rev2] example2
C: 2 LOGIN "arnt" "trondheim"
</sourcecode>
<t>The server sees that the password is accepted, knows that it and its <t>The server sees that the password is accepted, knows that it and its
JMAP alter ego use the same password database, and issues a JMAPACCESS JMAP alter ego use the same password database, and issues a JMAPACCESS
response code:</t> capability:</t>
<t>S: * OK [JMAPACCESS "https://example.com/.s/[jmap]"] For JMAP access
S: 2 OK done</t> <sourcecode type="">
<t>The URL uses the same quoting rules as most other IMAP strings, and S: * OK [CAPABILITY IMAP4rev2 JMAPACCESS] done
"]" is permitted in quoted strings. Permitted but in this case not S: 2 OK done
encouraged, since some clients are known to scan for the "]" before C: 2b JMAPACCESS
parsing the string inside "[]". Luckily, few URLs contain "]".</t> S: * JMAPACCESS "https://example.com/.s/[jmap]"
<t>Example 3. A client connects, sees no SASL method it recognises, and S: 2b OK done
</sourcecode>
<t>The URL uses the same quoting rules as most other IMAP strings.</t>
<t>Example 3:</t> <t>A client connects, sees no SASL method it recognizes,
and
issues a LOGIN command with a correct password.</t> issues a LOGIN command with a correct password.</t>
<t>S: * OK [CAPABILITY IMAP4rev1 IMAP4rev2] example3<br/>
C: 3 LOGIN "arnt" "trondheim"</t> <sourcecode type="">
S: * OK [CAPABILITY IMAP4rev1 IMAP4rev2] example3
C: 3 LOGIN "arnt" "trondheim"
</sourcecode>
<t>The server operator has decided to disable password use with JMAP, but <t>The server operator has decided to disable password use with JMAP, but
allow it for a while with IMAP to cater to older clients, so the login allow it for a while with IMAP to cater to older clients. Therefore, the login
succeeds, but there is no JMAPACCESS response code.</t> succeeds, but there is no JMAPACCESS capability.</t>
<t>S: 3 OK done</t>
<t>Example 4. A client connects, sees no SASL method it recognises, and <sourcecode type="">
S: 3 OK done
</sourcecode>
<t>Example 4:</t> <t>A client connects, sees no SASL method it recognizes,
and
issues a LOGIN command. Its password is incorrect.</t> issues a LOGIN command. Its password is incorrect.</t>
<t>S: * OK [CAPABILITY IMAP4rev2 AUTH=GSS] example4<br/>
C: 4 LOGIN "arnt" "oslo"</t> <sourcecode type="">
S: * OK [CAPABILITY IMAP4rev2 AUTH=GSS] example4
C: 4 LOGIN "arnt" "oslo"
</sourcecode>
<t>The server does not enter Authenticated state, so nothing requires it <t>The server does not enter Authenticated state, so nothing requires it
to issue JMAPACCESS. It replies curtly:</t> to mention JMAPACCESS. It replies curtly:</t>
<t>S: 4 NO done</t>
</section> <sourcecode type="">
S: 4 NO done
</sourcecode>
</section>
<section anchor="IANA"> <section anchor="IANA">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The IANA is requested to add the JMAPACCESS response code to the IMAP <t>The IANA has added the JMAPACCESS capability to the "Internet Message A
Response Codes registry, with this document as reference.</t> ccess Protocol (IMAP) Capabilities Registry" and listed this document as the ref
erence.</t>
</section> </section>
<section anchor="Security"> <section anchor="Security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The JMAPACCESS response code reveals to authenticated IMAP clients that <t>JMAPACCESS reveals to authenticated IMAP clients that
they would be able to authenticate via JMAP using the same credentials, they would be able to authenticate via JMAP using the same credentials
and that the object IDs match.</t> and that the object IDs match.</t>
<t>One does not normally wish reveal anything at all about authentication.
However, in this case information is revealed to an authenticated client, <t>One does not normally reveal anything at all about authentication.
the revealed URL can usually be found via JMAP autodiscovery, and an However, if the client is an attacker, then the attacker is known to
attacker would only need to try the credentials used once anyway (a matter have valid credentials, and <xref target="RFC8620" sectionFormat="of" section="2
of a second or two). Therefore, it is believed that this document does not .2"/> tells the attacker
how to find the revealed URL without the help of this extension.
Therefore, it is believed that this document does not
benefit an attacker noticeably, and its value for migration far outweighs benefit an attacker noticeably, and its value for migration far outweighs
its risk.</t> its risk.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <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="RFC3501">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.35
<title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title> 01.xml"/>
<author fullname="M. Crispin" initials="M." surname="Crispin"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
<date month="March" year="2003"/> 74.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
<t>The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) 51.xml"/>
allows a client to access and manipulate electronic mail messages on a server. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way th 19.xml"/>
at is functionally equivalent to local folders. IMAP4rev1 also provides the capa <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
bility for an offline client to resynchronize with the server. IMAP4rev1 include 74.xml"/>
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="RFC8474">
<front>
<title>IMAP Extension for Object Identifiers</title>
<author fullname="B. Gondwana" initials="B." role="editor" surname="
Gondwana"/>
<date month="September" year="2018"/>
<abstract>
<t>This document updates RFC 3501 (IMAP4rev1) with persistent iden
tifiers on mailboxes and messages to allow clients to more efficiently reuse cac
hed data when resources have changed location on the server.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8474"/>
<seriesInfo name="DOI" value="10.17487/RFC8474"/>
</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>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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="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="RFC6530">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65
<title>Overview and Framework for Internationalized Email</title> 30.xml"/>
<author fullname="J. Klensin" initials="J." surname="Klensin"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.68
<author fullname="Y. Ko" initials="Y." surname="Ko"/> 55.xml"/>
<date month="February" year="2012"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.68
<abstract> 57.xml"/>
<t>Full use of electronic mail throughout the world requires that <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.68
(subject to other constraints) people be able to use close variations on their o 58.xml"/>
wn names (written correctly in their own languages and scripts) as mailbox names <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.76
in email addresses. This document introduces a series of specifications that de 28.xml"/>
fine mechanisms and protocol extensions needed to fully support internationalize <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
d email addresses. These changes include an SMTP extension and extension of emai 20.xml"/>
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="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="RFC7628">
<front>
<title>A Set of Simple Authentication and Security Layer (SASL) Mech
anisms for OAuth</title>
<author fullname="W. Mills" initials="W." surname="Mills"/>
<author fullname="T. Showalter" initials="T." surname="Showalter"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<date month="August" year="2015"/>
<abstract>
<t>OAuth enables a third-party application to obtain limited acces
s to a protected resource, either on behalf of a resource owner by orchestrating
an approval interaction or by allowing the third-party application to obtain ac
cess on its own behalf.</t>
<t>This document defines how an application client uses credential
s obtained via OAuth over the Simple Authentication and Security Layer (SASL) to
access a protected resource at a resource server. Thereby, it enables schemes d
efined within the OAuth framework for non-HTTP-based application protocols.</t>
<t>Clients typically store the user's long-term credential. This d
oes, however, lead to significant security vulnerabilities, for example, when su
ch a credential leaks. A significant benefit of OAuth for usage in those clients
is that the password is replaced by a shared secret with higher entropy, i.e.,
the token. Tokens typically provide limited access rights and can be managed and
revoked separately from the user's long-term password.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7628"/>
<seriesInfo name="DOI" value="10.17487/RFC7628"/>
</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>
</references> </references>
</references> </references>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA7VZ2XYbNxJ9x1dgmAfbORS1WF7Ck42SaZseWVJEOcv4+MwB
u0Gyo2aDAdCimRz9y3zLfNncKqA3yonnYeZF6gUN1HKr6lZxb29POK+K9J8q
N4UeSm9LLbK15Svnjw4Ovjo4EonyQ+l8Klw5W2XOZabw2zWWT8bXL4WyWg3l
aL3OMyzEOyc2i6Ec/3x9NRIiNUmhVlibWjX3e5n28z390Vu19+tKrVWSaOeE
8JnPseZ6qeWbt6PL0enpeDqV449eF3SanBsrJ3gh1Gxm9e2Qb1pLRa4KnKkL
cbMZCin3wmq6eMOflX5p7FDsySDMyBZevirzmYXyDp9JaSw2mJyOzs9x47zV
Gko/lVemSOWlybB+mizLlSqKvjxJB/IQy5LMb4fyBKZyOnf0wKTY/fDg+IBv
ysJbWqDzRVau8EivVJYPpcLx3y+a4wdrm90OCoMVpc2Gcun92g3392HQohhA
sv1S1bKfWBjkFcTaqEJVgr9UztPeLdnP9K3O5VFfHh4ey5+yPM/USk79oJb7
rc5nprSFlj9OTmvhHx8cdIQfAQdW4eNG/BkkWHw/j0d6rVaDxKx2ha/e8zsh
CmNXgMetJv9cvTx9/OTgMF4+P352HC+/OniCpyIr5jvLnz55fFBdPn/ypLl8
1lw+/8unz54eVZfPnx5hM7G3tyfVjNRLvBDXy8xJwLVcaTg71fOs0E6qImBN
11j0RubayyTPsM7Jm8JspF8qjz9arABntcB3GRbShvyx0/ZWW7hdS5U7I9Ut
7KJmuZa3mWKE9nFQKpdmM5ATLzMHC+C8VKcM/eosPgZu9yTEKltY5bXE37RU
eb6lh7QXECFLp8WbjtxObjJIVNQahU0HwQyrLE1zLcQXcgK3m7RMKJKFGBUd
DYBHWCbJSZNKZ9nWOYOU5HTnDSkbFRb3FR7IlxDTZStKG4BjX5oCKigAD480
9NK/ldmtynWRaDKIK9drYz0s8pAOdYgFSOWlmTcC8Hmdo2bGL4MGsC9b5NFg
19XsktrfsC9bcm3NbZZqvJiVi0VWLGQNSgIBlBdkjZkmD22UJV/hs2BVfIXg
M2ttg9lN6SXFuEq2UBAa2cL15WaZJUsBUeCtVM627dw3wxe0PwuHQ6ol0Aeb
DshTV2Qhq1cMjTMkwBJGIOW0vNFbuTE2dbL39t30utcP/+X5BV9fjX94N7ka
v6Dr6evR2Vl9IeKK6euLd2cvmqvmy9OLt2/H5y/Cx3gqO49E7+3ol15Ac+/i
8npycT4669XR0NicAMSKEdDt2mryrHIi1S6x2Qw3+Obk9PLf/0L2+uOPvyFq
jw4Pv7q7izfPD58d42az1EU4jeETbmGirVDrtVaWdkFswJTrzMOWWOukQ5wV
EnbUsOOX78kyH4by61myPjz+Nj4ghTsPK5t1HrLN7j+593Ew4icefeKY2pqd
5zuW7so7+qVzX9m99fDr73LAW+4dPv/uW0HgeaE9hakQJwi6FLHtM0cg990S
DLupWZZzgHLYxUyGgmerhJTNpRIU9DPzkXJPDEe5VBROa4WtkxIpQ5rZrzrx
cvKC/SRD8YenKVB1RsAWk5i/OHc9dFrD3bFY3N31ww3VCLienM73lM3v7h6x
gAVnYU4On5AICAyHZlV+IJ04pCjevUlMHtCUeUHi15lm8mIQIisagCEScnk0
nubFFydvxqfX0LDOu/2YWih6RZD3mKA7qNkO9mROJa12qMdJTK2ArdlUAlOw
VMK0ioyDg/Ice/d8sxkJ2ENo4fMq17m1TrJ55GeIQnxbGBwxn5NDKvPk2Vz7
jDjGZE6ZmFOZiG4iX1YLyXJVUoWbc1rtdEJUKUdJsq2yVvuk+naF9LpUtxoC
aiomOUf+TPuNDiul35gKG5Tofoo7VKaHo6JA9DAI+QAJ8OLV5Hx/9O769fj8
GjzuekylZEUSUurXlGYc2AwJ5MkSOBXc1+sOsKGDQ9a3YXMuBfUhzCLrjwdk
JHq5Wx9RJnA1t2bVEbD9NTkhqhFDCLGUWJ3Se6BKunIOb3GKbB8q7tv1PiDB
J6FyO4iBqzX00szwBFRE6BcU7AouL24qbLXgA7NP+SLUVNRgABPe4xJnNRXi
JjYqz85ztXAhF3NEpcorURfhKr5CCp4rSiJybUIsfganNlS6KqQ1hwODqBaC
uDFML2pYBjOhDBeUoKgkIO+rZhMKafnabLDC9mv9RVcCq8HSYfjgpn6oYzgV
0Q3mSFWdbvlsOtMacCgouqaMEAhRK0NRiPCuR1D33PgmztumJ+cz0wmVsWBB
wL9/h/GZfyPjpJYDQDQJkugxcuBABlTuEM/KkH1KhjVmI6prK6OzK7Ucn49O
zsby3fXL598Qfi6vW3mYqHcn1dqQVEVwJBeKhhhGLmR1okHkOZWVTFmjBnKe
6RwcpUK1IBumqM1EaYn6Nq8ndT3oCPOsXQeI69/dCSLM+qMiFulgkAm0Iqx/
Qi+SPFBQXbE+Cn7n9VqQ/GwQplo7jelVFVCnFFBi520n3OiQuaFUHvgbHVgs
cl1HXlR9twaE8hD8t99i1D6YNzcRodjeaiQcosmpQEjdrwS75CtWMiazuXRb
pIOPNVRjccVyrmDMapelQ7dEau2RSq3OXX4je43mPTm9lL+VQHYal1Og8Dfy
m335qQ1iUe3KEKp9RwZ4CazeguI9ZF2adozqyUwL5sdEtRkqx1bfHlKC2WhE
l3L1w6NHndhzZqXr7gpMBU7reM81eRzBTuDoiwy+cdSYE6rmMaCCi+nJgw8P
IM/ccIeEpBN25XAw1NPhIDNneHVOGsgpNA1J+d3VWRAvpmoX2ZF80HtAEUxH
QG0B9mwzd7NliI4j5OUfX1SXd0KccVPjKAxn7VrGaX1NkZkGXJ4O+wTJncUB
QgJ30+FAjlWyrEKLaicxQDZ5nVJmMAvk5MBJdzaBr6BPEXJgYFkLjdXcuoa5
ThZTrW7xTkjliGkasYFJHriqGNTbVwKhhup8DltcacC6OYrbKwRMseAC3d23
L1cllIpv2+xBKLsoQ2/FJW1OIxFyJe12fTblAHX18RTlSQnfFq1U0BfU+i2W
ECr6RB4O5KjyQZQRQiCnRSYwHU3P5AUJwumpambZXh0CEkcMPBAgBEyH8kt5
8Xf5/hSnn0zOJte/tEKBNvyGtz0Zj67GV3zO3uTqQyX/4dcz+604HcrDjhVk
+5tZ9nF5+fOPv/9jMBj8MD7pEOIdVhaZlys5yuclfMyTDZqWuGZcEg3BwXtB
2gVcRE4UmbgL6UzlxCz1wrAHajLMnwF4yY3mA2duiwS+GsgTnShaaeb1fkzN
muPlwwJ55JGoKfaN5oT6a+k8JY3SdUYW9KiqRXFMA5hT9fvz5B8mImBM+XbI
PjpkH7U+6FXzsugIGpftU4LsfUDGLlBeupCIBCXgn9MlDbaoOQqWo6lLAG6V
+EUdIa4VZ2mT2laUrCyiBhGRJTLXxQImZadgi3hCC8NHf47hwgQErzSQT86j
6m8WBfojFzBcGS0Q9gopnwHwUY3TowqnR3GDHg1Teyh7Fu3HUmerXgeXTWSR
pms0rjQXqTrBNezQb4OyAZ34C9A1+xDHnSmnY9dY6daaTHcAMWyp+TkMDNz+
e8LBBwDhZdUSx6o5Jf2xSQAIqUs1o6zCj2WkQkz1xJaUnYDdlQGsAzUP5NBb
vI9u6X3okVHAXFeZ98HzoZRX6wbysn5J06mKViRQn/ijaLqEPpEctC+d8koV
hyzNE1QqoHXxpLNDyRRULasxRDgX51Ddlb33H3oDeVYmN1m+7cu53pDOrqqR
tEkLoo//9xANpY4GlNZS11xh4LO59z6IH1cgfvzfgZgaCgX+xyOVFPEfh41p
FjJUDUcCKYsZuh+4SfAYgbQkayuaOea6IUo8suSWHRcmT3U9bIa1QluYmwX6
Ks7kOnW8acP8C/OnzDfY5XED08o3x/+H9IF07DrRDfwFP30us4TS+Go6rb1z
XHnneMc7xuWm65i6d+LxwqenCzAjViw5FAN1cTRegr1Dw9XYj4sK1QrqHdEq
+apoHMvzi2jEL+RkdD5C4xHmFOEHN3A+enoXZOMFWSBK1MwwVNBy7c72uqUq
DgH4d7NOf0MbLVAZLKIusr3OJLfVgDARnWqITgTrnozVm7vPtExwi6YpyM70
I223rSFfC6bYG1PmNEKSHAw7XzXlu2wyC+XH1rylL2rWwVS/mlPSbxk+Ifp2
UejG2fxTFrHWTeaWUVqAcxucHFv6MB7oDn0Goh44dLJn+5cFdhztGP1W7Ngg
qN+PHURcSNmfMmrpwi9B/KtEWaQt7lJ6g3SRGJy+DdVKFUJ5T8TJRhPyDL3Q
4WQ4PHC51lyKOQH9fkHqUsv8UJGJPNH71hCQ8vrGPGKKbDmx95l+OZpKZhC6
NnbnJ7doX/Q1hZ5zJZa1gHieJRoO3vZrWnir8pL72PhbGP9STHPm0m90tlg6
weQLLVL8lYtYovgPXRbIcvUeAAA=
</back>
</rfc> </rfc>
 End of changes. 34 change blocks. 
404 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.48.