Diff: rfc9755.original

	rfc9755.original	rfc9755.txt


	EXTRA P. Resnick	Internet Engineering Task Force (IETF) P. Resnick
	Internet-Draft Episteme Technology Consulting LLC	Request for Comments: 9755 Episteme Technology Consulting LLC
	Obsoletes: 6855 (if approved) J. Yao	Obsoletes: 6855 J. Yao
	Intended status: Standards Track CNNIC	Category: Standards Track CNNIC
	Expires: 17 May 2025 A. Gulbrandsen	ISSN: 2070-1721 A. Gulbrandsen
	ICANN	ICANN

	13 November 2024	February 2025

	IMAP Support for UTF-8	IMAP Support for UTF-8

	draft-ietf-extra-6855bis-04

	Abstract	Abstract


	This specification extends the Internet Message Access Protocol	This specification extends the Internet Message Access Protocol,
	(IMAP4rev1, RFC 3501) to support UTF-8 encoded international	specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded
	characters in user names, mail addresses, and message headers. This	international characters in user names, mail addresses, and message
	specification replaces RFC 6855. This specification does not extend	headers. This specification replaces RFC 6855. This specification
	IMAP4rev2 [RFC9051], since that protocol includes everything in this	does not extend IMAP4rev2 (RFC 9051), since that protocol includes
	extension.	everything in this extension.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.

	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.


	Internet-Drafts are draft documents valid for a maximum of six months	This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any	(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference	received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."	Internet Engineering Steering Group (IESG). Further information on
		Internet Standards is available in Section 2 of RFC 7841.


	This Internet-Draft will expire on 17 May 2025.	Information about the current status of this document, any errata,
		and how to provide feedback on it may be obtained at
		https://www.rfc-editor.org/info/rfc9755.

	Copyright Notice	Copyright Notice


	Copyright (c) 2024 IETF Trust and the persons identified as the	Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal

	Provisions Relating to IETF Documents (https://trustee.ietf.org/	Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Introduction
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3	2. Requirements Language
	3. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP	3. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings
	Quoted-Strings . . . . . . . . . . . . . . . . . . . . . 3	4. "APPEND" Command
	4. "APPEND" Command . . . . . . . . . . . . . . . . . . . . . . 4	5. "LOGIN" Command and UTF-8
	5. "LOGIN" Command and UTF-8 . . . . . . . . . . . . . . . . . . 5	6. FETCH BODYSTRUCTURE and message/global
	6. FETCH BODYSTRUCTURE and message/global . . . . . . . . . . . 5	7. "UTF8=ONLY" Capability
	7. "UTF8=ONLY" Capability . . . . . . . . . . . . . . . . . . . 5	8. Dealing with Legacy Clients
	8. Dealing with Legacy Clients . . . . . . . . . . . . . . . . . 6	9. Issues with UTF-8 Header Mailstore
	9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . 7	10. IANA Considerations
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8	11. Security Considerations
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 8	12. References
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8	12.1. Normative References
	12.1. Normative References . . . . . . . . . . . . . . . . . . 8	12.2. Informative References
	12.2. Informative References . . . . . . . . . . . . . . . . . 9	Appendix A. Design Rationale
	Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 10	Appendix B. Changes since RFC 6855
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 10	B.1. APPEND UTF8
	Appendix C. Changes since RFC 6855 . . . . . . . . . . . . . . . 11	B.2. FETCH BODYSTRUCTURE
	C.1. APPEND UTF8 . . . . . . . . . . . . . . . . . . . . . . . 11	Acknowledgments
	C.2. FETCH BODYSTRUCTURE . . . . . . . . . . . . . . . . . . . 12	Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12

	1. Introduction	1. Introduction

	This specification forms part of the Email Address	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 [RFC6530]. It extends IMAP	Internationalization Framework document [RFC6530]. It extends IMAP
	[RFC3501] to permit UTF-8 [RFC3629] in headers, as described in	[RFC3501] to permit UTF-8 [RFC3629] in headers, as described in
	"Internationalized Email Headers" [RFC6532]. It also adds a	"Internationalized Email Headers" [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

	skipping to change at page 3, line 6 ¶	skipping to change at line 93 ¶

	This specification assumes that the IMAP server will be operating in	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 Section 3. 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 Section 7
	below.	below.

	This specification replaces an earlier, experimental approach to the	This specification replaces an earlier, experimental approach to the

	same problem [RFC5738] as well as [RFC6855].	same problem; see [RFC5738] as well as [RFC6855].

	2. Requirements Language	2. Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	3. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings	3. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings

	skipping to change at page 3, line 42 ¶	skipping to change at line 129 ¶
	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.	only valid in the authenticated state.

	The IMAP base specification [RFC3501] forbids the use of 8-bit	The IMAP base specification [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 [RFC2088], this requires an extra round trip for each UTF-8	literals [RFC2088], this requires an extra round trip for each UTF-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

	syntax:	ABNF syntax [RFC5234]:


	quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE ; QUOTED-CHAR is not modified,	quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE
	as it will affect ; other RFC 3501 ABNF non-terminals.	; QUOTED-CHAR is not modified, as it will affect
		; other RFC 3501 ABNF non-terminals.


	uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4	uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4


	UTF8-2 = <Defined in Section 4 of RFC 3629>	UTF8-2 = <Defined in Section 4 of RFC 3629>


	UTF8-3 = <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>
		UTF8-4 = <Defined in Section 4 of RFC 3629>

	When this extended quoting mechanism is used by the client, the	When this extended quoting mechanism is used by the client, the
	server MUST reject, with a "BAD" response, any octet sequences with	server MUST reject, with a "BAD" response, any octet sequences with
	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 [RFC3629]. The IMAP server MUST NOT send UTF-8	requirements of UTF-8 [RFC3629]. The IMAP server MUST NOT 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.	support for that syntax by using the "ENABLE UTF8=ACCEPT" command.

	If the server supports "UTF8=ACCEPT", the client MAY use extended	If the server supports "UTF8=ACCEPT", the client MAY 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.	permitted or not permitted are described in the following paragraphs.

	All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in	All IMAP servers that support "UTF8=ACCEPT" SHOULD accept 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, MUST accept	Naming Convention described in [RFC3501], Section 5.1.3, MUST 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 MUST comply with the Net-Unicode	internal format. Mailbox names MUST comply with the Net-Unicode
	Definition ([RFC5198], Section 2) with the specific exception that	Definition ([RFC5198], Section 2) with the specific exception that

	they MUST NOT contain control characters (U+0000-U+001F and U+0080-U+	they MUST NOT contain control characters (U+0000 - U+001F and U+0080
	009F), a delete character (U+007F), a line separator (U+2028), or a	- U+009F), a delete character (U+007F), a line separator (U+2028), or
	paragraph separator (U+2029).	a paragraph separator (U+2029).

	Once an IMAP client has enabled UTF-8 support with the "ENABLE	Once an IMAP client has enabled UTF-8 support with the "ENABLE
	UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that	UTF8=ACCEPT" command, it MUST NOT 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 SHOULD reject the command with	"SEARCH" command in that situation, it SHOULD reject the command with
	a "BAD" response (due to the conflicting charset labels).	a "BAD" response (due to the conflicting charset labels).

	4. "APPEND" Command	4. "APPEND" Command

	If the server supports "UTF8=ACCEPT", then the server accepts UTF-8	If the server supports "UTF8=ACCEPT", then the server accepts UTF-8

	skipping to change at page 5, line 22 ¶	skipping to change at line 201 ¶

	Although using the IMAP "AUTHENTICATE" command in this way makes it	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.	configured to use.

	6. FETCH BODYSTRUCTURE and message/global	6. FETCH BODYSTRUCTURE and message/global


	[RFC9051] section 7.5.2 treats message/global like message/rfc, which	[RFC9051], Section 7.5.2 treats message/global like message/rfc,
	means that for some messages, the response to FETCH BODYSTRUCTURE	which means that for some messages, the response to FETCH
	varies depending on whether IMAP4rev1 or IMAP4rev2 is in use.	BODYSTRUCTURE varies depending on whether IMAP4rev1 or IMAP4rev2 is
		in use.

	[RFC6855] does not extend [RFC3501] in this respect. This document	[RFC6855] does not extend [RFC3501] in this respect. This document
	extends the media-message ABNF production to match [RFC9051].	extends the media-message ABNF production to match [RFC9051].


	media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE ("RFC822" /	media-message = DQUOTE "MESSAGE" DQUOTE SP
	"GLOBAL") DQUOTE	DQUOTE ("RFC822" / "GLOBAL") DQUOTE

	When IMAP4rev1 and UTF8=ACCEPT has been enabled, the server MAY treat	When IMAP4rev1 and UTF8=ACCEPT has been enabled, the server MAY treat
	message/global like message/rfc822 when computing the body structure,	message/global like message/rfc822 when computing the body structure,
	but MAY also treat it as described in [RFC3501]. Clients MUST accept	but MAY also treat it as described in [RFC3501]. Clients MUST accept
	both cases.	both cases.

	When IMAP4rev2 and UTF8=ACCEPT are in use, the server MUST behave as	When IMAP4rev2 and UTF8=ACCEPT are in use, the server MUST behave as
	described in [RFC9051].	described in [RFC9051].

	7. "UTF8=ONLY" Capability	7. "UTF8=ONLY" Capability

	The "UTF8=ONLY" capability indicates that the server supports	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 Section 3) 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 [RFC3501]).	international mailbox name convention (modified UTF-7 [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 MUST use	announcement and client confirmation are necessary: clients MUST 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 [RFC5530], any command that might require UTF-8 support and	response [RFC5530], any command that might require UTF-8 support and
	is not preceded by an "ENABLE UTF8=ACCEPT" command.	is not preceded by an "ENABLE UTF8=ACCEPT" command.

	IMAP clients that find support for a server that announces	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 end-	announcement and provide an informative error message to the end
	user.	user.

	Because the "UTF8=ONLY" server capability includes support for	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".	used -- never "ENABLE UTF8=ONLY".

	8. Dealing with Legacy Clients	8. Dealing with Legacy Clients

	In most situations, it will be difficult or impossible for the	In most situations, it will be difficult or impossible for the

	skipping to change at page 7, line 6 ¶	skipping to change at line 281 ¶
	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" [RFC6857]) and trying to minimize	Internationalized Email Messages" [RFC6857]) and trying to minimize
	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"
	[RFC6858]).	[RFC6858]).

	Implementations that choose to perform downgrading SHOULD use one of	Implementations that choose to perform downgrading SHOULD use one of

	the standardized algorithms provided in RFC 6857 or RFC 6858.	the standardized algorithms provided in [RFC6857] or [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.	understood and carefully designed.

	Because such messages are really surrogates of the original ones, not	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 [RFC3501] did not anticipate. This	that the IMAP specification [RFC3501] did not anticipate. This
	brings up two concerns in particular: First, digital signatures	brings up two concerns in particular: First, digital signatures

	skipping to change at page 8, line 8 ¶	skipping to change at line 332 ¶
	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 [RFC3501] and the	server to comply with the IMAP base specification [RFC3501] and the
	Internet Message Format [RFC5322] with respect to all header	Internet Message Format [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.	discussed in Section 8.

	10. IANA Considerations	10. IANA Considerations


	the "IMAP 4 Capabilities" registry contains a number of references to	the "IMAP Capabilities" registry contained a number of references to
	RFC6855. IANA, please change them to point to this document instead	[RFC6855]. IANA has updated them point to this document instead.
	of RFC6855. The affected references are:	The affected references are:

	* UTF8=ACCEPT	* UTF8=ACCEPT

	* UTF8=ALL (OBSOLETE)	* UTF8=ALL (OBSOLETE)

	* UTF8=APPEND (OBSOLETE)	* UTF8=APPEND (OBSOLETE)

	* UTF8=ONLY	* UTF8=ONLY

	* UTF8=USER (OBSOLETE)	* UTF8=USER (OBSOLETE)

	skipping to change at page 8, line 43 ¶	skipping to change at line 367 ¶
	different protocols and/or support different capabilities. Those	different protocols and/or support different capabilities. Those
	issues are discussed in Section 8.	issues are discussed in Section 8.

	12. References	12. References

	12.1. Normative References	12.1. Normative References

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,

	<https://www.rfc-editor.org/rfc/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,	4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,

	<https://www.rfc-editor.org/rfc/rfc3501>.	<https://www.rfc-editor.org/info/rfc3501>.

	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November

	2003, <https://www.rfc-editor.org/rfc/rfc3629>.	2003, <https://www.rfc-editor.org/info/rfc3629>.

	[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names	[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
	and Passwords", RFC 4013, DOI 10.17487/RFC4013, February	and Passwords", RFC 4013, DOI 10.17487/RFC4013, February

	2005, <https://www.rfc-editor.org/rfc/rfc4013>.	2005, <https://www.rfc-editor.org/info/rfc4013>.

	[RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP	[RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
	ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March	ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March

	2008, <https://www.rfc-editor.org/rfc/rfc5161>.	2008, <https://www.rfc-editor.org/info/rfc5161>.

	[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network	[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
	Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,	Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,

	<https://www.rfc-editor.org/rfc/rfc5198>.	<https://www.rfc-editor.org/info/rfc5198>.

		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
		Specifications: ABNF", STD 68, RFC 5234,
		DOI 10.17487/RFC5234, January 2008,
		<https://www.rfc-editor.org/info/rfc5234>.

	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,	DOI 10.17487/RFC5322, October 2008,

	<https://www.rfc-editor.org/rfc/rfc5322>.	<https://www.rfc-editor.org/info/rfc5322>.

	[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for	[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
	Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,	Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,

	February 2012, <https://www.rfc-editor.org/rfc/rfc6530>.	February 2012, <https://www.rfc-editor.org/info/rfc6530>.

	[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized	[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
	Email Headers", RFC 6532, DOI 10.17487/RFC6532, February	Email Headers", RFC 6532, DOI 10.17487/RFC6532, February

	2012, <https://www.rfc-editor.org/rfc/rfc6532>.	2012, <https://www.rfc-editor.org/info/rfc6532>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	12.2. Informative References	12.2. Informative References

	[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,	[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
	DOI 10.17487/RFC2088, January 1997,	DOI 10.17487/RFC2088, January 1997,

	<https://www.rfc-editor.org/rfc/rfc2088>.	<https://www.rfc-editor.org/info/rfc2088>.

	[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,	[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
	DOI 10.17487/RFC2342, May 1998,	DOI 10.17487/RFC2342, May 1998,

	<https://www.rfc-editor.org/rfc/rfc2342>.	<https://www.rfc-editor.org/info/rfc2342>.

	[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",	[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
	RFC 4314, DOI 10.17487/RFC4314, December 2005,	RFC 4314, DOI 10.17487/RFC4314, December 2005,

	<https://www.rfc-editor.org/rfc/rfc4314>.	<https://www.rfc-editor.org/info/rfc4314>.

	[RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530,	[RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530,
	DOI 10.17487/RFC5530, May 2009,	DOI 10.17487/RFC5530, May 2009,

	<https://www.rfc-editor.org/rfc/rfc5530>.	<https://www.rfc-editor.org/info/rfc5530>.

	[RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8",	[RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8",
	RFC 5738, DOI 10.17487/RFC5738, March 2010,	RFC 5738, DOI 10.17487/RFC5738, March 2010,

	<https://www.rfc-editor.org/rfc/rfc5738>.	<https://www.rfc-editor.org/info/rfc5738>.

	[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP	[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
	Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March	Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March

	2013, <https://www.rfc-editor.org/rfc/rfc6855>.	2013, <https://www.rfc-editor.org/info/rfc6855>.

	[RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for	[RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for
	Internationalized Email Messages", RFC 6857,	Internationalized Email Messages", RFC 6857,
	DOI 10.17487/RFC6857, March 2013,	DOI 10.17487/RFC6857, March 2013,

	<https://www.rfc-editor.org/rfc/rfc6857>.	<https://www.rfc-editor.org/info/rfc6857>.

	[RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for	[RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
	Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,	Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,

	March 2013, <https://www.rfc-editor.org/rfc/rfc6858>.	March 2013, <https://www.rfc-editor.org/info/rfc6858>.

	[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application	[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
	Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July	Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July

	2019, <https://www.rfc-editor.org/rfc/rfc8620>.	2019, <https://www.rfc-editor.org/info/rfc8620>.

	[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message	[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
	Access Protocol (IMAP) - Version 4rev2", RFC 9051,	Access Protocol (IMAP) - Version 4rev2", RFC 9051,
	DOI 10.17487/RFC9051, August 2021,	DOI 10.17487/RFC9051, August 2021,

	<https://www.rfc-editor.org/rfc/rfc9051>.	<https://www.rfc-editor.org/info/rfc9051>.

	Appendix A. Design Rationale	Appendix A. Design Rationale

	This non-normative section discusses the reasons behind some of the	This non-normative section discusses the reasons behind some of the
	design choices in this specification.	design choices in this specification.

	The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability	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"	interoperability problems caused by a "just-send-UTF-8 IMAP"
	mechanism is the reason the "UTF8=ONLY" capability mechanism was	mechanism is the reason the "UTF8=ONLY" capability mechanism was
	chosen.	chosen.


	Appendix B. Acknowledgments	Appendix B. Changes since RFC 6855

	This document is an almost unchanged copy of [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 [RFC6855]. Jiankang Yao replaces him.

	The next paragraph is a straight copy of the acknowlegements in
	[RFC6855]:

	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.

	Many of them also reread the document during this revision.

	Appendix C. Changes since RFC 6855

	This non-normative section describes the changes made since	This non-normative section describes the changes made since
	[RFC6855].	[RFC6855].


	C.1. APPEND UTF8	B.1. APPEND UTF8

	This document removes APPEND's UTF8 data item, making the	This document removes APPEND's UTF8 data item, making the
	UTF8-related syntax compatible with IMAP4rev2 as defined by [RFC9051]	UTF8-related syntax compatible with IMAP4rev2 as defined by [RFC9051]
	and making it simpler for clients to support IMAP4rev1 and IMAP4rev2	and making it simpler for clients to support IMAP4rev1 and IMAP4rev2
	with the same code.	with the same code.

	IMAP4rev2 [RFC9051] provides roughly the same abilities as [RFC6855]	IMAP4rev2 [RFC9051] provides roughly the same abilities as [RFC6855]
	but does not include APPEND's UTF8 item. None of [RFC6855],	but does not include APPEND's UTF8 item. None of [RFC6855],

	IMAP4rev2 or JMAP [RFC8620] specify any way to learn whether a	IMAP4rev2, or JMAP [RFC8620] specify any way to learn whether a
	particular message was stored using the UTF8 data item. As of today,	particular message was stored using the UTF8 data item. As of today,
	an IMAP client cannot learn whether a particular message was stored	an IMAP client cannot learn whether a particular message was stored
	using the UTF8 data item, nor would it be able to trust that	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.	information.

	In July 2023, one of the authors found only one IMAP client that uses	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,	data item for all messages if the server supports UTF8=ACCEPT,
	without regard to whether a particular message includes any UTF8 at	without regard to whether a particular message includes any UTF8 at
	all).	all).

	For these reasons, it was judged best to revise [RFC6855] and adopt	For these reasons, it was judged best to revise [RFC6855] and adopt
	the same syntax as IMAP4rev2.	the same syntax as IMAP4rev2.


	C.2. FETCH BODYSTRUCTURE	B.2. FETCH BODYSTRUCTURE

	[RFC6532] defines a new MIME type, message/global, which is	[RFC6532] defines a new MIME type, message/global, which 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 [RFC6532]. [RFC3501] and [RFC9051]	(also) use the syntax defined in [RFC6532]. [RFC3501] and [RFC9051]
	define a FETCH item to return the MIME structure of a message, which	define a FETCH item to return the MIME structure of a message, which
	servers usually compute once and store.	servers usually compute once and store.

	None of the RFCs point out to implementers that IMAP4rev1 and	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.	way servers and clients often do can easily lead to problems.

	This document makes the syntax optional, making it simple for server	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	clients need to parse and handle both varieties, which they need to
	do anyway if they want to support both IMAP4rev1 and IMAP4rev2.	do anyway if they want to support both IMAP4rev1 and IMAP4rev2.


		Acknowledgments

		This document is an almost unchanged copy of [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 [RFC6855]. Jiankang Yao replaces him.

		The next paragraph is a straight copy of the acknowledgments in
		[RFC6855]:

		\| 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.

		Many of them also reread the document during this revision.

	Authors' Addresses	Authors' Addresses

	Pete Resnick	Pete Resnick
	Episteme Technology Consulting LLC	Episteme Technology Consulting LLC
	503 West Indiana Avenue	503 West Indiana Avenue

	Urbana, IL 61801-4941	Urbana, IL 61801-4941
	United States of America	United States of America
	Email: resnick@episteme.net	Email: resnick@episteme.net

	Jiankang Yao	Jiankang Yao
	CNNIC	CNNIC
	No.4 South 4th Zhongguancun Street	No.4 South 4th Zhongguancun Street
	Beijing	Beijing
	100190	100190
	China	China
	Email: yaojk@cnnic.cn	Email: yaojk@cnnic.cn

End of changes. 51 change blocks.
	124 lines changed or deleted	129 lines changed or added
This html diff was produced by rfcdiff 1.48.