< draft-ietf-extra-imap4rev2-01.txt		draft-ietf-extra-imap4rev2-02.txt >
	Network Working Group A. Melnikov, Ed.		Network Working Group A. Melnikov, Ed.
	Internet-Draft Isode Ltd		Internet-Draft Isode Ltd
	Obsoletes: 3501 (if approved) July 16, 2018		Obsoletes: 3501 (if approved) B. Leiba, Ed.
	Intended status: Standards Track		Intended status: Standards Track Huawei Technologies
	Expires: January 17, 2019		Expires: April 22, 2019 October 19, 2018
	INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2		INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
	draft-ietf-extra-imap4rev2-01.txt		draft-ietf-extra-imap4rev2-02.txt
	Abstract		Abstract
	The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)		The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
	allows a client to access and manipulate electronic mail messages on		allows a client to access and manipulate electronic mail messages on
	a server. IMAP4rev2 permits manipulation of mailboxes (remote		a server. IMAP4rev2 permits manipulation of mailboxes (remote
	message folders) in a way that is functionally equivalent to local		message folders) in a way that is functionally equivalent to local
	folders. IMAP4rev2 also provides the capability for an offline		folders. IMAP4rev2 also provides the capability for an offline
	client to resynchronize with the server.		client to resynchronize with the server.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 17, 2019.		This Internet-Draft will expire on April 22, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14		3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14
	3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14		3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14
	3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14		3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14
	3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14		3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14
	4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16		4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16		4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16
	4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17		4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17
	4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 17		4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18
	4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	5. Operational Considerations . . . . . . . . . . . . . . . . . 18		5. Operational Considerations . . . . . . . . . . . . . . . . . 18
	5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 18		5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 18
	5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 19		5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 19
	5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 19		5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 19
	5.1.3. Mailbox International Naming Convention . . . . . . . 20		5.2. Mailbox Size and Message Status Updates . . . . . . . . . 21
	5.2. Mailbox Size and Message Status Updates . . . . . . . . . 22		5.3. Response when no Command in Progress . . . . . . . . . . 21
	5.3. Response when no Command in Progress . . . . . . . . . . 22		5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 21
	5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 22		5.5. Multiple Commands in Progress (Command Pipelining) . . . 22
	5.5. Multiple Commands in Progress (Command Pipelining) . . . 23		6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 23
	6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 24		6.1. Client Commands - Any State . . . . . . . . . . . . . . . 23
	6.1. Client Commands - Any State . . . . . . . . . . . . . . . 24		6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 24
	6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 25		6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 25
	6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 26		6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 25
	6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 26		6.2. Client Commands - Not Authenticated State . . . . . . . . 26
	6.2. Client Commands - Not Authenticated State . . . . . . . . 27		6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 26
	6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 27		6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 27
	6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 28		6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 30
	6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 31		6.3. Client Commands - Authenticated State . . . . . . . . . . 31
	6.3. Client Commands - Authenticated State . . . . . . . . . . 32		6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 31
	6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 32		6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 33
	6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 34		6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35
	6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 36		6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 36
	6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 37		6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 37
	6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 38		6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38
	6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 39		6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 40
	6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 41		6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 41
	6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 42		6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 41
	6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 42		6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 44
	6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 45		6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 45
	6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 46		6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 49
	6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 50		6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 51
	6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 52		6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 54
	6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 55		6.4. Client Commands - Selected State . . . . . . . . . . . . 55
	6.4. Client Commands - Selected State . . . . . . . . . . . . 56		6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 56
	6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 57		6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 56
	6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 57		6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 57
	6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 58		6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 57
	6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 58		6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 58
	6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 59		6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 63
	6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 64		6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 67
	6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 68		6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 68
	6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 69		6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 69
	6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 70		6.5. Client Commands - Experimental/Expansion . . . . . . . . 71
	6.5. Client Commands - Experimental/Expansion . . . . . . . . 72		6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 71
	6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 72		7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 71
	7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 72		7.1. Server Responses - Status Responses . . . . . . . . . . . 72
	7.1. Server Responses - Status Responses . . . . . . . . . . . 73		7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 79
	7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 80		7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 80
	7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 81		7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 80
	7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 81		7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 81
	7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 82		7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 81
	7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 82		7.2. Server Responses - Server and Mailbox Status . . . . . . 82
	7.2. Server Responses - Server and Mailbox Status . . . . . . 83		7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 82
	7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 83		7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 82
	7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 83		7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 83
	7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 84		7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 86
	7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 87		7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 86
	7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 87		7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 86
	7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 87		7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 87
	7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 88		7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 87
	7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 88		7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 88
	7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 89		7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 88
	7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 89		7.3.2. RECENT Response . . . . . . . . . . . . . . . . . . . 88
	7.3.2. RECENT Response . . . . . . . . . . . . . . . . . . . 89		7.4. Server Responses - Message Status . . . . . . . . . . . . 89
	7.4. Server Responses - Message Status . . . . . . . . . . . . 90		7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 89
	7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 90		7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 90
	7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 91		7.5. Server Responses - Command Continuation Request . . . . . 95
	7.5. Server Responses - Command Continuation Request . . . . . 96		8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 95
	8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 96		9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 97
	9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 98
	10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 111		10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 111
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 111		11. Security Considerations . . . . . . . . . . . . . . . . . . . 111
	11.1. STARTTLS Security Considerations . . . . . . . . . . . . 112		11.1. STARTTLS Security Considerations . . . . . . . . . . . . 111
	11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 112		11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 111
	11.3. Other Security Considerations . . . . . . . . . . . . . 112		11.3. Other Security Considerations . . . . . . . . . . . . . 112
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 112
	12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 113		12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 113
	12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 114		12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 113
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 114		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
	13.1. Normative References . . . . . . . . . . . . . . . . . . 114		13.1. Normative References . . . . . . . . . . . . . . . . . . 113
	13.2. Informative References (related protocols) . . . . . . . 116		13.2. Informative References (related protocols) . . . . . . . 116
	13.3. Informative References (historical aspects of IMAP and		13.3. Informative References (historical aspects of IMAP and
	related protocols) . . . . . . . . . . . . . . . . . . . 117		related protocols) . . . . . . . . . . . . . . . . . . . 117
	Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 118		Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 118
	Appendix B. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 118		A.1. Mailbox International Naming Convention . . . . . . . . . 118
	Appendix C. Acknowledgement . . . . . . . . . . . . . . . . . . 119		Appendix B. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 120
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119		Appendix C. Acknowledgement . . . . . . . . . . . . . . . . . . 121
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 125		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127
	1. How to Read This Document		1. How to Read This Document
	1.1. Organization of This Document		1.1. Organization of This Document
	This document is written from the point of view of the implementor of		This document is written from the point of view of the implementor of
	an IMAP4rev2 client or server. Beyond the protocol overview in		an IMAP4rev2 client or server. Beyond the protocol overview in
	section 2, it is not optimized for someone trying to understand the		section 2, it is not optimized for someone trying to understand the
	operation of the protocol. The material in sections 3 through 5		operation of the protocol. The material in sections 3 through 5
	provides the general context and definitions with which IMAP4rev2		provides the general context and definitions with which IMAP4rev2
	skipping to change at page 16, line 35 ¶		skipping to change at page 16, line 35 ¶
	A "UID set" is similar to the sequence set of unique identifiers;		A "UID set" is similar to the sequence set of unique identifiers;
	however, the "*" value for a sequence number is not permitted.		however, the "*" value for a sequence number is not permitted.
	4.2. Number		4.2. Number
	A number consists of one or more digit characters, and represents a		A number consists of one or more digit characters, and represents a
	numeric value.		numeric value.
	4.3. String		4.3. String
	A string is in one of two forms: either literal or quoted string.		A string is in one of three forms: synchonizing literal, non-
	The literal form is the general form of string. The quoted string		synchronizing literal or quoted string. The synchronizing literal
	form is an alternative that avoids the overhead of processing a		form is the general form of string. The non-synchronizing literal
	literal at the cost of limitations of characters which may be used.		form is also the general form, but has length limitation. The quoted
			string form is an alternative that avoids the overhead of processing
			a literal at the cost of limitations of characters which may be used.
	A literal is a sequence of zero or more octets (including CR and LF),		When the distinction between synchronizing and non-synchronizing
	prefix-quoted with an octet count in the form of an open brace ("{"),		literals is not important, this document just uses the term
	the number of octets, close brace ("}"), and CRLF. In the case of		"literal".
	literals transmitted from server to client, the CRLF is immediately
	followed by the octet data. In the case of literals transmitted from
	client to server, the client MUST wait to receive a command
	continuation request (described later in this document) before
	sending the octet data (and the remainder of the command).
	A quoted string is a sequence of zero or more 7-bit characters,		A synchronizing literal is a sequence of zero or more octets
	excluding CR and LF, with double quote (<">) characters at each end.		(including CR and LF), prefix-quoted with an octet count in the form
			of an open brace ("{"), the number of octets, close brace ("}"), and
			CRLF. In the case of synchronizing literals transmitted from server
			to client, the CRLF is immediately followed by the octet data. In
			the case of synchronizing literals transmitted from client to server,
			the client MUST wait to receive a command continuation request
			(described later in this document) before sending the octet data (and
			the remainder of the command).
	The empty string is represented as either "" (a quoted string with		The non-synchronizing literal is an alternate form of synchronizing
	zero characters between double quotes) or as {0} followed by CRLF (a		literal, and it may appear in communication from client to server
	literal with an octet count of 0).		instead of the synchonizing form of literal. The non-synchronizing
			literal form MUST NOT be sent from server to client. The non-
			synchronizing literal is distinguished from the synchronizing literal
			by having a plus ("+") between the octet count and the closing brace
			("}"). The server does not generate a command continuation request
			in response to a non-synchronizing literal, and clients are not
			required to wait before sending the octets of a non- synchronizing
			literal. Non-synchronizing literals MUST NOT be larger than 4096
			octets. Any literal larger than 4096 bytes MUST be sent as a
			synchronizing literal. (Non-synchronizing literals defined in this
			document are the same as non-synchronizing literals defined by
			LITERAL- extension from [RFC7888]. See that document for details on
			how to handle invalid non-synchronizing literals longer than 4096
			octets and for interaction with other IMAP extensions.)
			A quoted string is a sequence of zero or more Unicode characters,
			excluding CR and LF, encoded in UTF-8, with double quote (<">)
			characters at each end.
			The empty string is represented as "" (a quoted string with zero
			characters between double quotes), as {0} followed by CRLF (a
			synchronizing literal with an octet count of 0) or as {0+} followed
			by CRLF (a non-synchronizing literal with an octet count of 0).
	Note: Even if the octet count is 0, a client transmitting a		Note: Even if the octet count is 0, a client transmitting a
	literal MUST wait to receive a command continuation request.		synchronizing literal MUST wait to receive a command continuation
			request.
	4.3.1. 8-bit and Binary Strings		4.3.1. 8-bit and Binary Strings
	8-bit textual and binary mail is supported through the use of a		8-bit textual and binary mail is supported through the use of a
	[MIME-IMB] content transfer encoding. IMAP4rev2 implementations MAY		[MIME-IMB] content transfer encoding. IMAP4rev2 implementations MAY
	transmit 8-bit or multi-octet characters in literals, but SHOULD do		transmit 8-bit or multi-octet characters in literals, but SHOULD do
	so only when the [CHARSET] is identified.		so only when the [CHARSET] is identified.
			IMAP4rev2 is compatible with [I18N-HDRS]. As a result, the
			identified charset for header-field values with 8-bit content is
			UTF-8 [UTF-8]. IMAP4rev2 implementations MUST accept and MAY
			transmit [UTF-8] text in quoted-strings as long as the string does
			not contain NUL, CR, or LF. This differs from IMAP4rev1
			implementations.
	Although a BINARY body encoding is defined, unencoded binary strings		Although a BINARY body encoding is defined, unencoded binary strings
	are not permitted. A "binary string" is any string with NUL		are not permitted. A "binary string" is any string with NUL
	characters. Implementations MUST encode binary data into a textual		characters. Implementations MUST encode binary data into a textual
	form, such as BASE64, before transmitting the data. A string with an		form, such as BASE64, before transmitting the data. A string with an
	excessive amount of CTL characters MAY also be considered to be		excessive amount of CTL characters MAY also be considered to be
	binary.		binary.
	4.4. Parenthesized List		4.4. Parenthesized List
	Data structures are represented as a "parenthesized list"; a sequence		Data structures are represented as a "parenthesized list"; a sequence
	skipping to change at page 18, line 12 ¶		skipping to change at page 18, line 43 ¶
	because addr-name uses "nstring" syntax which is NIL or a string,		because addr-name uses "nstring" syntax which is NIL or a string,
	but never an atom.		but never an atom.
	5. Operational Considerations		5. Operational Considerations
	The following rules are listed here to ensure that all IMAP4rev2		The following rules are listed here to ensure that all IMAP4rev2
	implementations interoperate properly.		implementations interoperate properly.
	5.1. Mailbox Naming		5.1. Mailbox Naming
	Mailbox names are 7-bit. Client implementations MUST NOT attempt to		In IMAP4rev2, Mailbox names are encoded in Net-Unicode [NET-UNICODE]
	create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox		(this differs from IMAP4rev1). Client implementations MAY attempt to
	names returned by LIST or LSUB as UTF-8. Server implementations		create Net-Unicode mailbox names, and MUST interpret any 8-bit
	SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT		mailbox names returned by LIST or LSUB as [NET-UNICODE]. Server
	return 8-bit mailbox names in LIST or LSUB. See Section 5.1.3 for		implementations MUST prohibit the creation of 8-bit mailbox names
	more information on how to represent non-ASCII mailbox names.		that do not comply with Net-Unicode (however, servers MAY accept a
			de-normalized UTF-8 mailbox name and convert it to Net-Unicode prior
	Note: 8-bit mailbox names were undefined in earlier versions of		to mailbox creation).
	this protocol. Some sites used a local 8-bit character set to
	represent non-ASCII mailbox names. Such usage is not
	interoperable, and is now formally deprecated.
	The case-insensitive mailbox name INBOX is a special name reserved to		The case-insensitive mailbox name INBOX is a special name reserved to
	mean "the primary mailbox for this user on this server". (Note that		mean "the primary mailbox for this user on this server". (Note that
	this special name may not exist on some servers for some users.) The		this special name may not exist on some servers for some users.) The
	interpretation of all other names is implementation-dependent.		interpretation of all other names is implementation-dependent.
	In particular, this specification takes no position on case		In particular, this specification takes no position on case
	sensitivity in non-INBOX mailbox names. Some server implementations		sensitivity in non-INBOX mailbox names. Some server implementations
	are fully case-sensitive; others preserve case of a newly-created		are fully case-sensitive in ASCII range; others preserve case of a
	name but otherwise are case-insensitive; and yet others coerce names		newly-created name but otherwise are case-insensitive; and yet others
	to a particular case. Client implementations MUST interact with any		coerce names to a particular case. Client implementations MUST
	of these. If a server implementation interprets non-INBOX mailbox		interact with any of these.
	names as case-insensitive, it MUST treat names using the
	international naming convention specially as described in
	Section 5.1.3.
	There are certain client considerations when creating a new mailbox		There are certain client considerations when creating a new mailbox
	name:		name:
	1. Any character which is one of the atom-specials (see the Formal		1. Any character which is one of the atom-specials (see the Formal
	Syntax) will require that the mailbox name be represented as a		Syntax) will require that the mailbox name be represented as a
	quoted string or literal.		quoted string or literal.
	2. CTL and other non-graphic characters are difficult to represent		2. CTL and other non-graphic characters are difficult to represent
	in a user interface and are best avoided.		in a user interface and are best avoided. Servers MAY refuse to
			create mailbox names containing Unicode CTL characters.
	3. Although the list-wildcard characters ("%" and "*") are valid in		3. Although the list-wildcard characters ("%" and "*") are valid in
	a mailbox name, it is difficult to use such mailbox names with		a mailbox name, it is difficult to use such mailbox names with
	the LIST and LSUB commands due to the conflict with wildcard		the LIST and LSUB commands due to the conflict with wildcard
	interpretation.		interpretation.
	4. Usually, a character (determined by the server implementation) is		4. Usually, a character (determined by the server implementation) is
	reserved to delimit levels of hierarchy.		reserved to delimit levels of hierarchy.
	5. Two characters, "#" and "&", have meanings by convention, and		5. Two characters, "#" and "&", have meanings by convention, and
	skipping to change at page 20, line 27 ¶		skipping to change at page 21, line 9 ¶
	The "Personal Mailbox" model, in which the default namespace that is		The "Personal Mailbox" model, in which the default namespace that is
	presented consists of only the user's personal mailboxes. To access		presented consists of only the user's personal mailboxes. To access
	shared mailboxes, the user must use an escape mechanism to reach		shared mailboxes, the user must use an escape mechanism to reach
	another namespace.		another namespace.
	The "Complete Hierarchy" model, in which the default namespace that		The "Complete Hierarchy" model, in which the default namespace that
	is presented includes the user's personal mailboxes along with any		is presented includes the user's personal mailboxes along with any
	other mailboxes they have access to.		other mailboxes they have access to.
	5.1.3. Mailbox International Naming Convention
	By convention, international mailbox names in IMAP4rev2 are specified
	using a modified version of the UTF-7 encoding described in [UTF-7].
	Modified UTF-7 may also be usable in servers that implement an
	earlier version of this protocol.
	In modified UTF-7, printable US-ASCII characters, except for "&",
	represent themselves; that is, characters with octet values 0x20-0x25
	and 0x27-0x7e. The character "&" (0x26) is represented by the two-
	octet sequence "&-".
	All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
	represented in modified BASE64, with a further modification from
	[UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
	used to represent any printing US-ASCII character which can represent
	itself. Only characters inside the modified BASE64 alphabet are
	permitted in modified BASE64 text.
	"&" is used to shift to modified BASE64 and "-" to shift back to US-
	ASCII. There is no implicit shift from BASE64 to US-ASCII, and null
	shifts ("-&" while in BASE64; note that "&-" while in US-ASCII means
	"&") are not permitted. However, all names start in US-ASCII, and
	MUST end in US-ASCII; that is, a name that ends with a non-ASCII
	ISO-10646 character MUST end with a "-").
	The purpose of these modifications is to correct the following
	problems with UTF-7:
	1. UTF-7 uses the "+" character for shifting; this conflicts with
	the common use of "+" in mailbox names, in particular USENET
	newsgroup names.
	2. UTF-7's encoding is BASE64 which uses the "/" character; this
	conflicts with the use of "/" as a popular hierarchy delimiter.
	3. UTF-7 prohibits the unencoded usage of "\"; this conflicts with
	the use of "\" as a popular hierarchy delimiter.
	4. UTF-7 prohibits the unencoded usage of "~"; this conflicts with
	the use of "~" in some servers as a home directory indicator.
	5. UTF-7 permits multiple alternate forms to represent the same
	string; in particular, printable US-ASCII characters can be
	represented in encoded form.
	Although modified UTF-7 is a convention, it establishes certain
	requirements on server handling of any mailbox name with an embedded
	"&" character. In particular, server implementations MUST preserve
	the exact form of the modified BASE64 portion of a modified UTF-7
	name and treat that text as case-sensitive, even if names are
	otherwise case-insensitive or case-folded.
	Server implementations SHOULD verify that any mailbox name with an
	embedded "&" character, used as an argument to CREATE, is: in the
	correctly modified UTF-7 syntax, has no superfluous shifts, and has
	no encoding in modified BASE64 of any printing US-ASCII character
	which can represent itself. However, client implementations MUST NOT
	depend upon the server doing this, and SHOULD NOT attempt to create a
	mailbox name with an embedded "&" character unless it complies with
	the modified UTF-7 syntax.
	Server implementations which export a mail store that does not follow
	the modified UTF-7 convention MUST convert to modified UTF-7 any
	mailbox name that contains either non-ASCII characters or the "&"
	character.
	For example, here is a mailbox name which mixes English, Chinese,
	and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
	For example, the string "&Jjo!" is not a valid mailbox name
	because it does not contain a shift to US-ASCII before the "!".
	The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is
	not permitted because it contains a superfluous shift. The
	correct form is "&U,BTF2XlZyyKng-".
	5.2. Mailbox Size and Message Status Updates		5.2. Mailbox Size and Message Status Updates
	At any time, a server can send data that the client did not request.		At any time, a server can send data that the client did not request.
	Sometimes, such behavior is REQUIRED. For example, agents other than		Sometimes, such behavior is REQUIRED. For example, agents other than
	the server MAY add messages to the mailbox (e.g., new message		the server MAY add messages to the mailbox (e.g., new message
	delivery), change the flags of the messages in the mailbox (e.g.,		delivery), change the flags of the messages in the mailbox (e.g.,
	simultaneous access to the same mailbox by multiple agents), or even		simultaneous access to the same mailbox by multiple agents), or even
	remove messages from the mailbox. A server MUST send mailbox size		remove messages from the mailbox. A server MUST send mailbox size
	updates automatically if a mailbox size change is observed during the		updates automatically if a mailbox size change is observed during the
	processing of a command. A server SHOULD send message flag updates		processing of a command. A server SHOULD send message flag updates
	skipping to change at page 37, line 29 ¶		skipping to change at page 36, line 29 ¶
	Responses: no specific responses for this command		Responses: no specific responses for this command
	Result: OK - create completed		Result: OK - create completed
	NO - create failure: can't create mailbox with that name		NO - create failure: can't create mailbox with that name
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	The CREATE command creates a mailbox with the given name. An OK		The CREATE command creates a mailbox with the given name. An OK
	response is returned only if a new mailbox with that name has been		response is returned only if a new mailbox with that name has been
	created. It is an error to attempt to create INBOX or a mailbox with		created. It is an error to attempt to create INBOX or a mailbox with
	a name that refers to an extant mailbox. Any error in creation will		a name that refers to an extant mailbox. Any error in creation will
	return a tagged NO response.		return a tagged NO response. If a client attempts to create a UTF-8
			mailbox name that is not a valid Net-Unicode name, the server MUST
			reject the creation or convert the name to Net-Unicode prior to
			creating the mailbox.
	If the mailbox name is suffixed with the server's hierarchy separator		If the mailbox name is suffixed with the server's hierarchy separator
	character (as returned from the server by a LIST command), this is a		character (as returned from the server by a LIST command), this is a
	declaration that the client intends to create mailbox names under		declaration that the client intends to create mailbox names under
	this name in the hierarchy. Server implementations that do not		this name in the hierarchy. Server implementations that do not
	require this declaration MUST ignore the declaration. In any case,		require this declaration MUST ignore the declaration. In any case,
	the name created is without the trailing hierarchy delimiter.		the name created is without the trailing hierarchy delimiter.
	If the server's hierarchy separator character appears elsewhere in		If the server's hierarchy separator character appears elsewhere in
	the name, the server SHOULD create any superior hierarchical names		the name, the server SHOULD create any superior hierarchical names
	skipping to change at page 52, line 7 ¶		skipping to change at page 51, line 7 ¶
	RECENT The number of messages with the \Recent flag set.		RECENT The number of messages with the \Recent flag set.
	UIDNEXT The next unique identifier value of the mailbox. Refer to		UIDNEXT The next unique identifier value of the mailbox. Refer to
	Section 2.3.1.1 for more information.		Section 2.3.1.1 for more information.
	UIDVALIDITY The unique identifier validity value of the mailbox.		UIDVALIDITY The unique identifier validity value of the mailbox.
	Refer to Section 2.3.1.1 for more information.		Refer to Section 2.3.1.1 for more information.
	UNSEEN The number of messages which do not have the \Seen flag set.		UNSEEN The number of messages which do not have the \Seen flag set.
	SIZE The total size of the mailbox in octets. This MUST be equal to		SIZE The total size of the mailbox in octets. This is not strictly
	the sum of the [RFC-5322] size of all messages in the mailbox.
	The total size of the mailbox in octets. This is not strictly
	required to be an exact value, but it MUST be equal to or greater		required to be an exact value, but it MUST be equal to or greater
	than the sum of the values of the RFC822.SIZE FETCH message data		than the sum of the values of the RFC822.SIZE FETCH message data
	items (see Section 6.4.6) of all messages in the mailbox.		items (see Section 6.4.6) of all messages in the mailbox.
	Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)		Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
	S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)		S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
	S: A042 OK STATUS completed		S: A042 OK STATUS completed
	6.3.13. APPEND Command		6.3.13. APPEND Command
	skipping to change at page 52, line 34 ¶		skipping to change at page 51, line 32 ¶
	Responses: no specific responses for this command		Responses: no specific responses for this command
	Result: OK - append completed		Result: OK - append completed
	NO - append error: can't append to that mailbox, error		NO - append error: can't append to that mailbox, error
	in flags or date/time or message text		in flags or date/time or message text
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	The APPEND command appends the literal argument as a new message to		The APPEND command appends the literal argument as a new message to
	the end of the specified destination mailbox. This argument SHOULD		the end of the specified destination mailbox. This argument SHOULD
	be in the format of an [RFC-5322] message. 8-bit characters are		be in the format of an [RFC-5322] or [I18N-HDRS] message. 8-bit
	permitted in the message. A server implementation that is unable to		characters are permitted in the message. A server implementation
	preserve 8-bit data properly MUST be able to reversibly convert 8-bit		that is unable to preserve 8-bit data properly MUST be able to
	APPEND data to 7-bit using a [MIME-IMB] content transfer encoding.		reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
			content transfer encoding.
	Note: There may be exceptions, e.g., draft messages, in which		Note: There may be exceptions, e.g., draft messages, in which
	required [RFC-5322] header lines are omitted in the message		required [RFC-5322] header lines are omitted in the message
	literal argument to APPEND. The full implications of doing so		literal argument to APPEND. The full implications of doing so
	must be understood and carefully weighed.		must be understood and carefully weighed.
	If a flag parenthesized list is specified, the flags SHOULD be set in		If a flag parenthesized list is specified, the flags SHOULD be set in
	the resulting message; otherwise, the flag list of the resulting		the resulting message; otherwise, the flag list of the resulting
	message is set to empty by default. In either case, the Recent flag		message is set to empty by default. In either case, the Recent flag
	is also set.		is also set.
	skipping to change at page 61, line 9 ¶		skipping to change at page 60, line 9 ¶
	one or more search keys (e.g., for use with the OR and NOT keys).		one or more search keys (e.g., for use with the OR and NOT keys).
	Server implementations MAY exclude [MIME-IMB] body parts with		Server implementations MAY exclude [MIME-IMB] body parts with
	terminal content media types other than TEXT and MESSAGE from		terminal content media types other than TEXT and MESSAGE from
	consideration in SEARCH matching.		consideration in SEARCH matching.
	The OPTIONAL [CHARSET] specification consists of the word "CHARSET"		The OPTIONAL [CHARSET] specification consists of the word "CHARSET"
	followed by a registered [CHARSET]. It indicates the [CHARSET] of		followed by a registered [CHARSET]. It indicates the [CHARSET] of
	the strings that appear in the search criteria. [MIME-IMB] content		the strings that appear in the search criteria. [MIME-IMB] content
	transfer encodings, and [MIME-HDRS] strings in [RFC-5322]/[MIME-IMB]		transfer encodings, and [MIME-HDRS] strings in [RFC-5322]/[MIME-IMB]
	headers, MUST be decoded before comparing text. US-ASCII MUST be		headers, MUST be decoded before comparing text. US-ASCII and UTF-8
	supported; other [CHARSET]s MAY be supported.		charsets MUST be supported; other [CHARSET]s MAY be supported. If
			"CHARSET" is not provided, an IMAP4rev2 server MUST assume UTF-8.
	If the server does not support the specified [CHARSET], it MUST		If the server does not support the specified [CHARSET], it MUST
	return a tagged NO response (not a BAD). This response SHOULD		return a tagged NO response (not a BAD). This response SHOULD
	contain the BADCHARSET response code, which MAY list the [CHARSET]s		contain the BADCHARSET response code, which MAY list the [CHARSET]s
	supported by the server.		supported by the server.
	In all search keys that use strings, a message matches the key if the		In all search keys that use strings, a message matches the key if the
	string is a substring of the associated text. The matching is case-		string is a substring of the associated text. The matching SHOULD be
	insensitive. Note that the empty string is a substring; this is		case-insensitive for characters within ASCII range. Consider using
	useful when doing a HEADER search.		[IMAP-I18N] for language-sensitive case-insensitive searching. Note
			that the empty string is a substring; this is useful when doing a
			HEADER search in order to test for a header field presence in the
			message.
	The defined search keys are as follows. Refer to the Formal Syntax		The defined search keys are as follows. Refer to the Formal Syntax
	section for the precise syntactic definitions of the arguments.		section for the precise syntactic definitions of the arguments.
	<sequence set> Messages with message sequence numbers corresponding		<sequence set> Messages with message sequence numbers corresponding
	to the specified message sequence number set.		to the specified message sequence number set.
	ALL All messages in the mailbox; the default initial key for ANDing.		ALL All messages in the mailbox; the default initial key for ANDing.
	ANSWERED Messages with the \Answered flag set.		ANSWERED Messages with the \Answered flag set.
	skipping to change at page 65, line 43 ¶		skipping to change at page 64, line 43 ¶
	Every message has at least one part number. Non-[MIME-IMB]		Every message has at least one part number. Non-[MIME-IMB]
	messages, and non-multipart [MIME-IMB] messages with no		messages, and non-multipart [MIME-IMB] messages with no
	encapsulated message, only have a part 1.		encapsulated message, only have a part 1.
	Multipart messages are assigned consecutive part numbers, as		Multipart messages are assigned consecutive part numbers, as
	they occur in the message. If a particular part is of type		they occur in the message. If a particular part is of type
	message or multipart, its parts MUST be indicated by a period		message or multipart, its parts MUST be indicated by a period
	followed by the part number within that nested multipart part.		followed by the part number within that nested multipart part.
	A part of type MESSAGE/RFC822 also has nested part numbers,		A part of type MESSAGE/RFC822 or MESSAGE/GLOBAL also has nested
	referring to parts of the MESSAGE part's body.		part numbers, referring to parts of the MESSAGE part's body.
	The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part		The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
	specifiers can be the sole part specifier or can be prefixed by		specifiers can be the sole part specifier or can be prefixed by
	one or more numeric part specifiers, provided that the numeric		one or more numeric part specifiers, provided that the numeric
	part specifier refers to a part of type MESSAGE/RFC822. The		part specifier refers to a part of type MESSAGE/RFC822 or
	MIME part specifier MUST be prefixed by one or more numeric		MESSAGE/GLOBAL. The MIME part specifier MUST be prefixed by
	part specifiers.		one or more numeric part specifiers.
	The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part		The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
	specifiers refer to the [RFC-5322] header of the message or of		specifiers refer to the [RFC-5322] header of the message or of
	an encapsulated [MIME-IMT] MESSAGE/RFC822 message.		an encapsulated [MIME-IMT] MESSAGE/RFC822 or MESSAGE/GLOBAL
	HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of		message. HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a
	field-name (as defined in [RFC-5322]) names, and return a		list of field-name (as defined in [RFC-5322]) names, and return
	subset of the header. The subset returned by HEADER.FIELDS		a subset of the header. The subset returned by HEADER.FIELDS
	contains only those header fields with a field-name that		contains only those header fields with a field-name that
	matches one of the names in the list; similarly, the subset		matches one of the names in the list; similarly, the subset
	returned by HEADER.FIELDS.NOT contains only the header fields		returned by HEADER.FIELDS.NOT contains only the header fields
	with a non-matching field-name. The field-matching is case-		with a non-matching field-name. The field-matching is ASCII
	insensitive but otherwise exact. Subsetting does not exclude		range case-insensitive but otherwise exact. Subsetting does
	the [RFC-5322] delimiting blank line between the header and the		not exclude the [RFC-5322] delimiting blank line between the
	body; the blank line is included in all header fetches, except		header and the body; the blank line is included in all header
	in the case of a message which has no body and no blank line.		fetches, except in the case of a message which has no body and
			no blank line.
	The MIME part specifier refers to the [MIME-IMB] header for		The MIME part specifier refers to the [MIME-IMB] header for
	this part.		this part.
	The TEXT part specifier refers to the text body of the message,		The TEXT part specifier refers to the text body of the message,
	omitting the [RFC-5322] header.		omitting the [RFC-5322] header.
	Here is an example of a complex message with some of its		Here is an example of a complex message with some of its
	part specifiers:		part specifiers:
	skipping to change at page 91, line 37 ¶		skipping to change at page 90, line 37 ¶
	truncated.		truncated.
	Note: The origin octet facility MUST NOT be used by a server		Note: The origin octet facility MUST NOT be used by a server
	in a FETCH response unless the client specifically requested		in a FETCH response unless the client specifically requested
	it by means of a FETCH of a BODY[<section>]<<partial>> data		it by means of a FETCH of a BODY[<section>]<<partial>> data
	item.		item.
	8-bit textual data is permitted if a [CHARSET] identifier is		8-bit textual data is permitted if a [CHARSET] identifier is
	part of the body parameter parenthesized list for this section.		part of the body parameter parenthesized list for this section.
	Note that headers (part specifiers HEADER or MIME, or the		Note that headers (part specifiers HEADER or MIME, or the
	header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit		header portion of a MESSAGE/RFC822 or MESSAGE/GLOBAL part), MAY
	characters are not permitted in headers. Note also that the		be in UTF-8. Note also that the [RFC-5322] delimiting blank
	[RFC-5322] delimiting blank line between the header and the		line between the header and the body is not affected by header
	body is not affected by header line subsetting; the blank line		line subsetting; the blank line is always included as part of
	is always included as part of header data, except in the case		header data, except in the case of a message which has no body
	of a message which has no body and no blank line.		and no blank line.
	Non-textual data such as binary data MUST be transfer encoded		Non-textual data such as binary data MUST be transfer encoded
	into a textual form, such as BASE64, prior to being sent to the		into a textual form, such as BASE64, prior to being sent to the
	client. To derive the original binary data, the client MUST		client. To derive the original binary data, the client MUST
	decode the transfer encoded string.		decode the transfer encoded string.
	BODYSTRUCTURE		BODYSTRUCTURE
	A parenthesized list that describes the [MIME-IMB] body		A parenthesized list that describes the [MIME-IMB] body
	structure of a message. This is computed by the server by		structure of a message. This is computed by the server by
	skipping to change at page 96, line 14 ¶		skipping to change at page 95, line 14 ¶
	7.5. Server Responses - Command Continuation Request		7.5. Server Responses - Command Continuation Request
	The command continuation request response is indicated by a "+" token		The command continuation request response is indicated by a "+" token
	instead of a tag. This form of response indicates that the server is		instead of a tag. This form of response indicates that the server is
	ready to accept the continuation of a command from the client. The		ready to accept the continuation of a command from the client. The
	remainder of this response is a line of text.		remainder of this response is a line of text.
	This response is used in the AUTHENTICATE command to transmit server		This response is used in the AUTHENTICATE command to transmit server
	data to the client, and request additional client data. This		data to the client, and request additional client data. This
	response is also used if an argument to any command is a literal.		response is also used if an argument to any command is a
			synchronizing literal.
	The client is not permitted to send the octets of the literal unless		The client is not permitted to send the octets of the synchronizing
	the server indicates that it is expected. This permits the server to		literal unless the server indicates that it is expected. This
	process commands and reject errors on a line-by-line basis. The		permits the server to process commands and reject errors on a line-
	remainder of the command, including the CRLF that terminates a		by-line basis. The remainder of the command, including the CRLF that
	command, follows the octets of the literal. If there are any		terminates a command, follows the octets of the literal. If there
	additional command arguments, the literal octets are followed by a		are any additional command arguments, the literal octets are followed
	space and those arguments.		by a space and those arguments.
	Example: C: A001 LOGIN {11}		Example: C: A001 LOGIN {11}
	S: + Ready for additional command text		S: + Ready for additional command text
	C: FRED FOOBAR {7}		C: FRED FOOBAR {7}
	S: + Ready for additional command text		S: + Ready for additional command text
	C: fat man		C: fat man
	S: A001 OK LOGIN completed		S: A001 OK LOGIN completed
	C: A044 BLURDYBLOOP {102856}		C: A044 BLURDYBLOOP {102856}
	S: A044 BAD No such command as "BLURDYBLOOP"		S: A044 BAD No such command as "BLURDYBLOOP"
	skipping to change at page 100, line 33 ¶		skipping to change at page 99, line 33 ¶
	body-fld-md5 = nstring		body-fld-md5 = nstring
	body-fld-octets = number		body-fld-octets = number
	body-fld-param = "(" string SP string *(SP string SP string) ")" / nil		body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
	body-type-1part = (body-type-basic / body-type-msg / body-type-text)		body-type-1part = (body-type-basic / body-type-msg / body-type-text)
	[SP body-ext-1part]		[SP body-ext-1part]
	body-type-basic = media-basic SP body-fields		body-type-basic = media-basic SP body-fields
	; MESSAGE subtype MUST NOT be "RFC822"		; MESSAGE subtype MUST NOT be "RFC822" or "GLOBAL"
	body-type-mpart = 1*body SP media-subtype		body-type-mpart = 1*body SP media-subtype
	[SP body-ext-mpart]		[SP body-ext-mpart]
	; MULTIPART body part		; MULTIPART body part
	body-type-msg = media-message SP body-fields SP envelope		body-type-msg = media-message SP body-fields SP envelope
	SP body SP body-fld-lines		SP body SP body-fld-lines
	body-type-text = media-text SP body-fields SP body-fld-lines		body-type-text = media-text SP body-fields SP body-fld-lines
	skipping to change at page 103, line 51 ¶		skipping to change at page 102, line 51 ¶
	; Section 5.1 of [RFC4422]		; Section 5.1 of [RFC4422]
	list = "LIST" SP mailbox SP list-mailbox		list = "LIST" SP mailbox SP list-mailbox
	list-mailbox = 1*list-char / string		list-mailbox = 1*list-char / string
	list-char = ATOM-CHAR / list-wildcards / resp-specials		list-char = ATOM-CHAR / list-wildcards / resp-specials
	list-wildcards = "%" / "*"		list-wildcards = "%" / "*"
	literal = "{" number "}" CRLF *CHAR8		literal = "{" number ["+"] "}" CRLF *CHAR8
	; Number represents the number of CHAR8s		; Number represents the number of CHAR8s.
			; A non-synchronizing literal is distinguished
			; from a synchronizing literal by presence of the "+"
			; before the closing "}".
			; Non synchronizing literals are not allowed when sent
			; from server to the client.
	login = "LOGIN" SP userid SP password		login = "LOGIN" SP userid SP password
	lsub = "LSUB" SP mailbox SP list-mailbox		lsub = "LSUB" SP mailbox SP list-mailbox
	mailbox = "INBOX" / astring		mailbox = "INBOX" / astring
	; INBOX is case-insensitive. All case variants of		; INBOX is case-insensitive. All case variants of
	; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX		; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
	; not as an astring. An astring which consists of		; not as an astring. An astring which consists of
	; the case-insensitive sequence "I" "N" "B" "O" "X"		; the case-insensitive sequence "I" "N" "B" "O" "X"
	skipping to change at page 104, line 43 ¶		skipping to change at page 103, line 49 ¶
	mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"		mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
	; Selectability flags; only one per LIST response		; Selectability flags; only one per LIST response
	media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /		media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
	"MESSAGE" / "VIDEO" / "FONT") DQUOTE) / string) SP		"MESSAGE" / "VIDEO" / "FONT") DQUOTE) / string) SP
	media-subtype		media-subtype
	; Defined in [MIME-IMT].		; Defined in [MIME-IMT].
	; FONT defined in RFC YYYY.		; FONT defined in RFC YYYY.
	media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE		media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE ("RFC822" / "GLOBAL") DQUOTE
	; Defined in [MIME-IMT]		; Defined in [MIME-IMT]
	media-subtype = string		media-subtype = string
	; Defined in [MIME-IMT]		; Defined in [MIME-IMT]
	media-text = DQUOTE "TEXT" DQUOTE SP media-subtype		media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
	; Defined in [MIME-IMT]		; Defined in [MIME-IMT]
	message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))		message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
	msg-att = "(" (msg-att-dynamic / msg-att-static)		msg-att = "(" (msg-att-dynamic / msg-att-static)
	*(SP (msg-att-dynamic / msg-att-static)) ")"		*(SP (msg-att-dynamic / msg-att-static)) ")"
	msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"		msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
	; MAY change for a message		; MAY change for a message
	msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /		msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
	"RFC822" [".HEADER" / ".TEXT"] SP nstring /		"RFC822" [".HEADER" / ".TEXT"] SP nstring /
	"RFC822.SIZE" SP number /		"RFC822.SIZE" SP number /
	"BODY" ["STRUCTURE"] SP body /		"BODY" ["STRUCTURE"] SP body /
	skipping to change at page 106, line 4 ¶		skipping to change at page 105, line 11 ¶
	number64 = 1*DIGIT		number64 = 1*DIGIT
	; Unsigned 63-bit integer		; Unsigned 63-bit integer
	; (0 <= n <= 9,223,372,036,854,775,807)		; (0 <= n <= 9,223,372,036,854,775,807)
	nz-number = digit-nz *DIGIT		nz-number = digit-nz *DIGIT
	; Non-zero unsigned 32-bit integer		; Non-zero unsigned 32-bit integer
	; (0 < n < 4,294,967,296)		; (0 < n < 4,294,967,296)
	password = astring		password = astring
	partial-range = number ["." nz-number]		partial-range = number ["." nz-number]
	; Copied from RFC 5092 (IMAP URL)		; Copied from RFC 5092 (IMAP URL)
	partial = "<" number "." nz-number ">"		partial = "<" number "." nz-number ">"
	; Partial FETCH request. 0-based offset of		; Partial FETCH request. 0-based offset of
	; the first octet, followed by the number of octets		; the first octet, followed by the number of octets
	; in the fragment.		; in the fragment.
	quoted = DQUOTE *QUOTED-CHAR DQUOTE		quoted = DQUOTE *QUOTED-CHAR DQUOTE
	QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /		QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
	"\" quoted-specials		"\" quoted-specials / UTF8-2 / UTF8-3 / UTF8-4
	quoted-specials = DQUOTE / "\"		quoted-specials = DQUOTE / "\"
	rename = "RENAME" SP mailbox SP mailbox		rename = "RENAME" SP mailbox SP mailbox
	; Use of INBOX as a destination gives a NO error		; Use of INBOX as a destination gives a NO error
	response = *(continue-req / response-data) response-done		response = *(continue-req / response-data) response-done
	response-data = "*" SP (resp-cond-state / resp-cond-bye /		response-data = "*" SP (resp-cond-state / resp-cond-bye /
	mailbox-data / message-data / capability-data /		mailbox-data / message-data / capability-data /
	skipping to change at page 108, line 44 ¶		skipping to change at page 107, line 51 ¶
	; Data for the returned search option.		; Data for the returned search option.
	; A single "nz-number"/"number"/"number64" value		; A single "nz-number"/"number"/"number64" value
	; can be returned as an atom (i.e., without		; can be returned as an atom (i.e., without
	; quoting). A sequence-set can be returned		; quoting). A sequence-set can be returned
	; as an atom as well.		; as an atom as well.
	section = "[" [section-spec] "]"		section = "[" [section-spec] "]"
	section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /		section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
	"TEXT"		"TEXT"
	; top-level or MESSAGE/RFC822 part		; top-level or MESSAGE/RFC822 or MESSAGE/GLOBAL part
	section-part = nz-number *("." nz-number)		section-part = nz-number *("." nz-number)
	; body part reference.		; body part reference.
	; Allows for accessing nested body parts.		; Allows for accessing nested body parts.
	section-spec = section-msgtext / (section-part ["." section-text])		section-spec = section-msgtext / (section-part ["." section-text])
	section-text = section-msgtext / "MIME"		section-text = section-msgtext / "MIME"
	; text other than actual body part (headers, etc.)		; text other than actual body part (headers, etc.)
	skipping to change at page 111, line 29 ¶		skipping to change at page 110, line 36 ¶
	; between these two regards of order.		; between these two regards of order.
	; Example: 2:4 and 4:2 are equivalent.		; Example: 2:4 and 4:2 are equivalent.
	uniqueid = nz-number		uniqueid = nz-number
	; Strictly ascending		; Strictly ascending
	unsubscribe = "UNSUBSCRIBE" SP mailbox		unsubscribe = "UNSUBSCRIBE" SP mailbox
	userid = astring		userid = astring
			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>
	x-command = "X" atom <experimental command arguments>		x-command = "X" atom <experimental command arguments>
	zone = ("+" / "-") 4DIGIT		zone = ("+" / "-") 4DIGIT
	; Signed four-digit value of hhmm representing		; Signed four-digit value of hhmm representing
	; hours and minutes east of Greenwich (that is,		; hours and minutes east of Greenwich (that is,
	; the amount that the given time differs from		; the amount that the given time differs from
	; Universal Time). Subtracting the timezone		; Universal Time). Subtracting the timezone
	; from the given time will give the UT form.		; from the given time will give the UT form.
	; The Universal Time zone is "+0000".		; The Universal Time zone is "+0000".
	skipping to change at page 116, line 9 ¶		skipping to change at page 115, line 26 ¶
	2006, <http://www.rfc-editor.org/info/rfc4422>.		2006, <http://www.rfc-editor.org/info/rfc4422>.
	[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008,		(TLS) Protocol Version 1.2", RFC 5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
	[UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe		[UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe
	Transformation Format of Unicode", RFC 2152, May 1997,		Transformation Format of Unicode", RFC 2152, May 1997,
	<http://www.rfc-editor.org/info/rfc2152>.		<http://www.rfc-editor.org/info/rfc2152>.
			[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
			10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
			2003, <http://www.rfc-editor.org/info/rfc3629>.
	[MULTIAPPEND]		[MULTIAPPEND]
	Crispin, M., "Internet Message Access Protocol (IMAP) -		Crispin, M., "Internet Message Access Protocol (IMAP) -
	MULTIAPPEND Extension", RFC 3502, March 2003,		MULTIAPPEND Extension", RFC 3502, March 2003,
	<http://www.rfc-editor.org/info/rfc3502>.		<http://www.rfc-editor.org/info/rfc3502>.
	[IMAP-IMPLEMENTATION]		[IMAP-IMPLEMENTATION]
	Leiba, B., "IMAP4 Implementation Recommendations",		Leiba, B., "IMAP4 Implementation Recommendations",
	RFC 2683, September 1999,		RFC 2683, September 1999,
	<http://www.rfc-editor.org/info/rfc2683>.		<http://www.rfc-editor.org/info/rfc2683>.
	[IMAP-MULTIACCESS]		[IMAP-MULTIACCESS]
	Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",		Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
	RFC 2180, July 1997,		RFC 2180, July 1997,
	<http://www.rfc-editor.org/info/rfc2180>.		<http://www.rfc-editor.org/info/rfc2180>.
			[NET-UNICODE]
			Klensin, J. and M. Padlipsky, "Unicode Format for Network
			Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
			<https://www.rfc-editor.org/info/rfc5198>.
			[I18N-HDRS]
			Yang, A., Steele, S., and N. Freed, "Internationalized
			Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
			2012, <https://www.rfc-editor.org/info/rfc6532>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)		[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
	Server Identity Check Procedure for Email-Related		Server Identity Check Procedure for Email-Related
	Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,		Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
	<https://www.rfc-editor.org/info/rfc7817>.		<https://www.rfc-editor.org/info/rfc7817>.
			[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
			RFC 7888, DOI 10.17487/RFC7888, May 2016,
			<https://www.rfc-editor.org/info/rfc7888>.
	[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:		[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
	Use of Transport Layer Security (TLS) for Email Submission		Use of Transport Layer Security (TLS) for Email Submission
	and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,		and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
	<https://www.rfc-editor.org/info/rfc8314>.		<https://www.rfc-editor.org/info/rfc8314>.
	13.2. Informative References (related protocols)		13.2. Informative References (related protocols)
	[IMAP-DISC]		[IMAP-DISC]
	Melnikov, A., Ed., "Synchronization Operations for		Melnikov, A., Ed., "Synchronization Operations for
	Disconnected IMAP4 Clients", RFC 4549, June 2006,		Disconnected IMAP4 Clients", RFC 4549, June 2006,
	<http://www.rfc-editor.org/info/rfc4549>.		<http://www.rfc-editor.org/info/rfc4549>.
			[IMAP-I18N]
			Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
			Message Access Protocol Internationalization", RFC 5255,
			DOI 10.17487/RFC5255, June 2008,
			<http://www.rfc-editor.org/info/rfc5255>.
	[IMAP-MODEL]		[IMAP-MODEL]
	Crispin, M., "Distributed Electronic Mail Models in		Crispin, M., "Distributed Electronic Mail Models in
	IMAP4", RFC 1733, December 1994,		IMAP4", RFC 1733, December 1994,
	<http://www.rfc-editor.org/info/rfc1733>.		<http://www.rfc-editor.org/info/rfc1733>.
			[IMAP-UTF-8]
			Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
			Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
			2013, <http://www.rfc-editor.org/info/rfc6855>.
	[ACAP] Newman, C. and J. G. Myers, "ACAP -- Application		[ACAP] Newman, C. and J. G. Myers, "ACAP -- Application
	Configuration Access Protocol", RFC 2244, November 1997,		Configuration Access Protocol", RFC 2244, November 1997,
	<http://www.rfc-editor.org/info/rfc2244>.		<http://www.rfc-editor.org/info/rfc2244>.
	[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	October 2008, <http://www.rfc-editor.org/info/rfc5321>.		October 2008, <http://www.rfc-editor.org/info/rfc5321>.
	[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",		[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
	RFC 4314, December 2005,		RFC 4314, December 2005,
	<http://www.rfc-editor.org/info/rfc4314>.		<http://www.rfc-editor.org/info/rfc4314>.
	skipping to change at page 118, line 14 ¶		skipping to change at page 118, line 14 ¶
	[IMAP-TLS]		[IMAP-TLS]
	Newman, C., "Using TLS with IMAP, POP3 and ACAP",		Newman, C., "Using TLS with IMAP, POP3 and ACAP",
	RFC 2595, June 1999,		RFC 2595, June 1999,
	<http://www.rfc-editor.org/info/rfc2595>.		<http://www.rfc-editor.org/info/rfc2595>.
	Appendix A. Backward compatibility with IMAP4rev1		Appendix A. Backward compatibility with IMAP4rev1
	An implementation that wants to remain compatible with IMAP4rev1 can		An implementation that wants to remain compatible with IMAP4rev1 can
	advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/		advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/
	response code. While some IMAP4rev1 response were removed in		response code. While some IMAP4rev1 responses were removed in
	IMAP4rev2, their presence will not break IMAP4rev2-only clients.		IMAP4rev2, their presence will not break IMAP4rev2-only clients.
	If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that		If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
	wants to use IMAP4rev2 MUST issue "ENABLE IMAP4rev2" command.		wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
			Servers advertising both IMAP4rev1 and IMAP4rev2 SHOULD NOT generate
			UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".
			Consider implementation of mechanisms described or referenced in
			[IMAP-UTF-8] to achieve this goal.
			Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
			intending to be compatible with IMAP4rev1 servers MUST be compatible
			with the international mailbox naming convention described in the
			following subsection.
			A.1. Mailbox International Naming Convention
			By convention, international mailbox names in IMAP4rev2 are specified
			using a modified version of the UTF-7 encoding described in [UTF-7].
			Modified UTF-7 may also be usable in servers that implement an
			earlier version of this protocol.
			In modified UTF-7, printable US-ASCII characters, except for "&",
			represent themselves; that is, characters with octet values 0x20-0x25
			and 0x27-0x7e. The character "&" (0x26) is represented by the two-
			octet sequence "&-".
			All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
			represented in modified BASE64, with a further modification from
			[UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
			used to represent any printing US-ASCII character which can represent
			itself. Only characters inside the modified BASE64 alphabet are
			permitted in modified BASE64 text.
			"&" is used to shift to modified BASE64 and "-" to shift back to US-
			ASCII. There is no implicit shift from BASE64 to US-ASCII, and null
			shifts ("-&" while in BASE64; note that "&-" while in US-ASCII means
			"&") are not permitted. However, all names start in US-ASCII, and
			MUST end in US-ASCII; that is, a name that ends with a non-ASCII
			ISO-10646 character MUST end with a "-").
			The purpose of these modifications is to correct the following
			problems with UTF-7:
			1. UTF-7 uses the "+" character for shifting; this conflicts with
			the common use of "+" in mailbox names, in particular USENET
			newsgroup names.
			2. UTF-7's encoding is BASE64 which uses the "/" character; this
			conflicts with the use of "/" as a popular hierarchy delimiter.
			3. UTF-7 prohibits the unencoded usage of "\"; this conflicts with
			the use of "\" as a popular hierarchy delimiter.
			4. UTF-7 prohibits the unencoded usage of "~"; this conflicts with
			the use of "~" in some servers as a home directory indicator.
			5. UTF-7 permits multiple alternate forms to represent the same
			string; in particular, printable US-ASCII characters can be
			represented in encoded form.
			Although modified UTF-7 is a convention, it establishes certain
			requirements on server handling of any mailbox name with an embedded
			"&" character. In particular, server implementations MUST preserve
			the exact form of the modified BASE64 portion of a modified UTF-7
			name and treat that text as case-sensitive, even if names are
			otherwise case-insensitive or case-folded.
			Server implementations SHOULD verify that any mailbox name with an
			embedded "&" character, used as an argument to CREATE, is: in the
			correctly modified UTF-7 syntax, has no superfluous shifts, and has
			no encoding in modified BASE64 of any printing US-ASCII character
			which can represent itself. However, client implementations MUST NOT
			depend upon the server doing this, and SHOULD NOT attempt to create a
			mailbox name with an embedded "&" character unless it complies with
			the modified UTF-7 syntax.
			Server implementations which export a mail store that does not follow
			the modified UTF-7 convention MUST convert to modified UTF-7 any
			mailbox name that contains either non-ASCII characters or the "&"
			character.
			For example, here is a mailbox name which mixes English, Chinese,
			and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
			For example, the string "&Jjo!" is not a valid mailbox name
			because it does not contain a shift to US-ASCII before the "!".
			The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is
			not permitted because it contains a superfluous shift. The
			correct form is "&U,BTF2XlZyyKng-".
	Appendix B. Changes from RFC 3501 / IMAP4rev1		Appendix B. Changes from RFC 3501 / IMAP4rev1
	The following is the plan for remaining changes. The plan might		The following is the plan for remaining changes. The plan might
	change over time.		change over time.
	1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response		1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response
	Codes, done), UIDPLUS (done), ENABLE (done), ESEARCH (done),		Codes, done), UIDPLUS (done), ENABLE (done), ESEARCH (done),
	SPECIAL-USE (list of new mailbox attributes is done), LITERAL-,		SPECIAL-USE (list of new mailbox attributes is done), LITERAL-
	NAMESPACE (done), SASL-IR (done).		(done), NAMESPACE (done), SASL-IR (done).
	2. Add CLOSED response code (from CONDSTORE) - done		2. Add CLOSED response code (from CONDSTORE) - done
	3. Add support for $MDNSent and $Forwarded IMAP keywords - done.		3. Add support for $MDNSent and $Forwarded IMAP keywords - done.
	Add more examples showing their use?		Add more examples showing their use?
	4. Require all unsolicited updates to include UID (?)		4. Require all unsolicited updates to include UID (?)
	5. Update recommendations on TLS ciphers to match UTA WG work (as		5. Update recommendations on TLS ciphers to match UTA WG work (as
	per RFC 8314, RFC 7525 and RFC 7817) - done.		per RFC 8314, RFC 7525 and RFC 7817) - done.
	6. Possibly fold in the following extensions/RFC: Base LIST-		6. Possibly fold in the following extensions/RFC: Base LIST-
	EXTENDED syntax plus deprecate LSUB (replace it with LIST		EXTENDED syntax plus deprecate LSUB (replace it with LIST
	\Subscribed) minus the requirement to support multiple list		\Subscribed) minus the requirement to support multiple list
	patterns, STATUS-in-LIST, Unique mailstore IDs for messages		patterns, STATUS-in-LIST, Unique mailstore IDs for messages
	(OBJECTID extension, see draft-ietf-extra-imap-objectid), IDLE		(OBJECTID extension, RFC 8474), IDLE (done), SEARCHRES, BINARY
	(done), SEARCHRES, BINARY.		(possibly only the FETCH changes and make APPEND related ones
			optional?).
	7. Add STATUS SIZE (total mailbox size) - done Add STATUS DELETED		7. Add STATUS SIZE (total mailbox size) - done Add STATUS DELETED
	(number of messages with \Deleted flag set)?		(number of messages with \Deleted flag set)?
	8. Deprecate features: RECENT response on SELECT/EXAMINE, \Recent		8. Deprecate features: RECENT response on SELECT/EXAMINE, \Recent
	flag, RECENT STATUS item. UNSEEN response code on SELECT/		flag, RECENT STATUS item. UNSEEN response code on SELECT/
	EXAMINE. SEARCH response (use ESEARCH instead).		EXAMINE. SEARCH response (use ESEARCH instead).
	9. Drop UTF-7, all mailboxes are always in UTF-8.		9. Drop UTF-7, all mailboxes are always in UTF-8 - done.
	10. Revise IANA registration of IMAP extensions and advice on use of		10. Revise IANA registration of IMAP extensions and advice on use of
	"X-" convention.		"X-" convention.
	The following changes since RFC 3501 were done so far:		The following changes since RFC 3501 were done so far:
	1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH		1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH
	(RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177) and SASL-IR (RFC		(RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177) and SASL-IR (RFC
	4959) extensions. Also folded RFC 5530.		4959) extensions. Also folded RFC 5530.
	skipping to change at page 119, line 29 ¶		skipping to change at page 121, line 22 ¶
	8314, RFC 7817, RFC 7525.		8314, RFC 7817, RFC 7525.
	4. For future extensibility extended ABNF for tagged-ext-simple to		4. For future extensibility extended ABNF for tagged-ext-simple to
	allow for bare number64.		allow for bare number64.
	5. Added SHOULD level requirement on IMAP servers to support		5. Added SHOULD level requirement on IMAP servers to support
	$MDNSent and $Forwarded keywords.		$MDNSent and $Forwarded keywords.
	6. Added STATUS SIZE.		6. Added STATUS SIZE.
			7. Mailbox names and message headers now allow for UTF-8. Support
			for Modified UTF-7 in mailbox names is not required, unless
			compatibility with IMAP4rev1 is desired.
	Appendix C. Acknowledgement		Appendix C. Acknowledgement
	Earlier versions of this document were edited by Mark Crispin.		Earlier versions of this document were edited by Mark Crispin.
	Sadly, he is no longer available to help with this work. Editor of		Sadly, he is no longer available to help with this work. Editor of
	this revisions is hoping that Mark would have approved.		this revisions is hoping that Mark would have approved.
			Chris Newman has contributed text on I18N and use of UTF-8 in
			messages and mailbox names.
	Thank you to Tony Hansen for helping with the index generation.		Thank you to Tony Hansen for helping with the index generation.
	This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC		This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC
	5161, RFC 6154 so work done by authors/editors of these documents is		5161, RFC 6154 so work done by authors/editors of these documents is
	appreciated.		appreciated.
	Index		Index
	$		$
	$Forwarded (predefined flag) 12		$Forwarded (predefined flag) 12
	$MDNSent (predefined flag) 12		$MDNSent (predefined flag) 12
	+		+
	+FLAGS <flag list> 68		+FLAGS <flag list> 67
	+FLAGS.SILENT <flag list> 68		+FLAGS.SILENT <flag list> 67
	-		-
	-FLAGS <flag list> 69		-FLAGS <flag list> 68
	-FLAGS.SILENT <flag list> 69		-FLAGS.SILENT <flag list> 68
	A		A
	ALERT (response code) 74		ALERT (response code) 73
	ALL (fetch item) 65		ALL (fetch item) 64
	ALL (search key) 61		ALL (search key) 60
	ALL (search result option) 60		ALL (search result option) 59
	ALREADYEXISTS (response code) 74		ALREADYEXISTS (response code) 73
	ANSWERED (search key) 61		ANSWERED (search key) 60
	APPEND (command) 52		APPEND (command) 51
	APPENDUID (response code) 74		APPENDUID (response code) 73
	AUTHENTICATE (command) 28		AUTHENTICATE (command) 27
	AUTHENTICATIONFAILED (response code) 75		AUTHENTICATIONFAILED (response code) 74
	AUTHORIZATIONFAILED (response code) 75		AUTHORIZATIONFAILED (response code) 74
	B		B
	BAD (response) 81		BAD (response) 80
	BADCHARSET (response code) 75		BADCHARSET (response code) 74
	BCC <string> (search key) 61		BCC <string> (search key) 60
	BEFORE <date> (search key) 61		BEFORE <date> (search key) 60
	BODY (fetch item) 65		BODY (fetch item) 64
	BODY (fetch result) 91		BODY (fetch result) 90
	BODY <string> (search key) 61		BODY <string> (search key) 60
	BODY.PEEK[<section>]<<partial>> (fetch item) 67		BODY.PEEK[<section>]<<partial>> (fetch item) 66
	BODYSTRUCTURE (fetch item) 67		BODYSTRUCTURE (fetch item) 66
	BODYSTRUCTURE (fetch result) 91		BODYSTRUCTURE (fetch result) 90
	BODY[<section>]<<origin octet>> (fetch result) 91		BODY[<section>]<<origin octet>> (fetch result) 90
	BODY[<section>]<<partial>> (fetch item) 65		BODY[<section>]<<partial>> (fetch item) 64
	BYE (response) 82		BYE (response) 81
	Body Structure (message attribute) 13		Body Structure (message attribute) 13
	C		C
	CANNOT (response code) 75		CANNOT (response code) 74
	CAPABILITY (command) 25		CAPABILITY (command) 24
	CAPABILITY (response code) 75		CAPABILITY (response code) 74
	CAPABILITY (response) 83		CAPABILITY (response) 82
	CC <string> (search key) 61		CC <string> (search key) 60
	CHECK (command) 57		CHECK (command) 56
	CLIENTBUG (response code) 75		CLIENTBUG (response code) 74
	CLOSE (command) 57		CLOSE (command) 56
	CLOSED (response code) 76		CLOSED (response code) 75
	CONTACTADMIN (response code) 76		CONTACTADMIN (response code) 75
	COPY (command) 69		COPY (command) 68
	COPYUID (response code) 76		COPYUID (response code) 75
	CORRUPTION (response code) 77		CORRUPTION (response code) 76
	COUNT (search result option) 60		COUNT (search result option) 59
	CREATE (command) 37		CREATE (command) 36
	D		D
	DELETE (command) 38		DELETE (command) 37
	DELETED (search key) 61		DELETED (search key) 60
	DRAFT (search key) 61		DRAFT (search key) 60
	E		E
	ENABLE (command) 32		ENABLE (command) 31
	ENVELOPE (fetch item) 67		ENVELOPE (fetch item) 66
	ENVELOPE (fetch result) 94		ENVELOPE (fetch result) 93
	ESEARCH (response) 88		ESEARCH (response) 87
	EXAMINE (command) 36		EXAMINE (command) 35
	EXPIRED (response code) 77		EXPIRED (response code) 76
	EXPUNGE (command) 58		EXPUNGE (command) 57
	EXPUNGE (response) 90		EXPUNGE (response) 89
	EXPUNGEISSUED (response code) 77		EXPUNGEISSUED (response code) 76
	Envelope Structure (message attribute) 13		Envelope Structure (message attribute) 13
	F		F
	FAST (fetch item) 65		FAST (fetch item) 64
	FETCH (command) 64		FETCH (command) 63
	FETCH (response) 91		FETCH (response) 90
	FLAGGED (search key) 61		FLAGGED (search key) 60
	FLAGS (fetch item) 67		FLAGS (fetch item) 66
	FLAGS (fetch result) 95		FLAGS (fetch result) 94
	FLAGS (response) 88		FLAGS (response) 87
	FLAGS <flag list> (store command data item) 68		FLAGS <flag list> (store command data item) 67
	FLAGS.SILENT <flag list> (store command data item) 68		FLAGS.SILENT <flag list> (store command data item) 67
	FROM <string> (search key) 61		FROM <string> (search key) 61
	FULL (fetch item) 65		FULL (fetch item) 64
	Flags (message attribute) 11		Flags (message attribute) 11
	H		H
	HEADER (part specifier) 65		HEADER (part specifier) 64
	HEADER <field-name> <string> (search key) 62		HEADER <field-name> <string> (search key) 61
	HEADER.FIELDS (part specifier) 65		HEADER.FIELDS (part specifier) 64
	HEADER.FIELDS.NOT (part specifier) 65		HEADER.FIELDS.NOT (part specifier) 64
	I		I
	IDLE (command) 55		IDLE (command) 54
	INTERNALDATE (fetch item) 67		INTERNALDATE (fetch item) 66
	INTERNALDATE (fetch result) 95		INTERNALDATE (fetch result) 94
	INUSE (response code) 77		INUSE (response code) 76
	Internal Date (message attribute) 13		Internal Date (message attribute) 13
	K		K
	KEYWORD <flag> (search key) 62		KEYWORD <flag> (search key) 61
	Keyword (type of flag) 12		Keyword (type of flag) 12
	L		L
	LARGER <n> (search key) 62		LARGER <n> (search key) 61
	LIMIT (response code) 78		LIMIT (response code) 77
	LIST (command) 42		LIST (command) 41
	LIST (response) 84		LIST (response) 83
	LOGOUT (command) 26		LOGOUT (command) 25
	LSUB (command) 45		LSUB (command) 44
	LSUB (response) 87		LSUB (response) 86
	M		M
	MAX (search result option) 60		MAX (search result option) 59
	MAY (specification requirement term) 5		MAY (specification requirement term) 5
	MESSAGES (status item) 51		MESSAGES (status item) 50
	MIME (part specifier) 66		MIME (part specifier) 65
	MIN (search result option) 59		MIN (search result option) 58
	MUST (specification requirement term) 5		MUST (specification requirement term) 5
	MUST NOT (specification requirement term) 5		MUST NOT (specification requirement term) 5
	Message Sequence Number (message attribute) 11		Message Sequence Number (message attribute) 11
	N		N
	NAMESPACE (command) 46		NAMESPACE (command) 45
	NAMESPACE (response) 87		NAMESPACE (response) 86
	NEW (search key) 62		NEW (search key) 61
	NO (response) 81		NO (response) 80
	NONEXISTENT (response code) 78		NONEXISTENT (response code) 77
	NOOP (command) 26		NOOP (command) 25
	NOPERM (response code) 78		NOPERM (response code) 77
	NOT <search-key> (search key) 62		NOT <search-key> (search key) 61
	O		O
	OK (response) 80		OK (response) 79
	OLD (search key) 62		OLD (search key) 61
	ON <date> (search key) 62		ON <date> (search key) 61
	OPTIONAL (specification requirement term) 5		OPTIONAL (specification requirement term) 5
	OR <search-key1> <search-key2> (search key) 62		OR <search-key1> <search-key2> (search key) 61
	OVERQUOTA (response code) 78		OVERQUOTA (response code) 77
	P		P
	PARSE (response code) 79		PARSE (response code) 78
	PERMANENTFLAGS (response code) 79		PERMANENTFLAGS (response code) 78
	PREAUTH (response) 82		PREAUTH (response) 81
	PRIVACYREQUIRED (response code) 79		PRIVACYREQUIRED (response code) 78
	Permanent Flag (class of flag) 12		Permanent Flag (class of flag) 12
	Predefined keywords 12		Predefined keywords 12
	R		R
	READ-ONLY (response code) 79		READ-ONLY (response code) 78
	READ-WRITE (response code) 79		READ-WRITE (response code) 78
	RECENT (search key) 62		RECENT (search key) 61
	RECENT (status item) 51		RECENT (status item) 50
	RECOMMENDED (specification requirement term) 5		RECOMMENDED (specification requirement term) 5
	RENAME (command) 39		RENAME (command) 38
	REQUIRED (specification requirement term) 5		REQUIRED (specification requirement term) 5
	RFC822 (fetch item) 67		RFC822 (fetch item) 66
	RFC822 (fetch result) 95		RFC822 (fetch result) 94
	RFC822.HEADER (fetch item) 67		RFC822.HEADER (fetch item) 66
	RFC822.HEADER (fetch result) 95		RFC822.HEADER (fetch result) 94
	RFC822.SIZE (fetch item) 67		RFC822.SIZE (fetch item) 66
	RFC822.SIZE (fetch result) 95		RFC822.SIZE (fetch result) 94
	RFC822.TEXT (fetch item) 67		RFC822.TEXT (fetch item) 66
	RFC822.TEXT (fetch result) 95		RFC822.TEXT (fetch result) 94
	S		S
	SEARCH (command) 59		SEARCH (command) 58
	SEEN (search key) 62		SEEN (search key) 61
	SELECT (command) 34		SELECT (command) 33
	SENTBEFORE <date> (search key) 62		SENTBEFORE <date> (search key) 61
	SENTON <date> (search key) 62		SENTON <date> (search key) 61
	SENTSINCE <date> (search key) 62		SENTSINCE <date> (search key) 61
	SERVERBUG (response code) 79		SERVERBUG (response code) 78
	SHOULD (specification requirement term) 5		SHOULD (specification requirement term) 5
	SHOULD NOT (specification requirement term) 5		SHOULD NOT (specification requirement term) 5
	SINCE <date> (search key) 62		SINCE <date> (search key) 61
	SIZE (status item) 52		SIZE (status item) 51
	SMALLER <n> (search key) 62		SMALLER <n> (search key) 62
	STARTTLS (command) 27		STARTTLS (command) 26
	STATUS (command) 50		STATUS (command) 49
	STATUS (response) 87		STATUS (response) 86
	STORE (command) 68		STORE (command) 67
	SUBJECT <string> (search key) 63		SUBJECT <string> (search key) 62
	SUBSCRIBE (command) 41		SUBSCRIBE (command) 40
	Session Flag (class of flag) 12		Session Flag (class of flag) 12
	System Flag (type of flag) 11		System Flag (type of flag) 11
	T		T
	TEXT (part specifier) 65		TEXT (part specifier) 64
	TEXT <string> (search key) 63		TEXT <string> (search key) 62
	TO <string> (search key) 63		TO <string> (search key) 62
	TRYCREATE (response code) 79		TRYCREATE (response code) 78
	U		U
	UID (command) 70		UID (command) 69
	UID (fetch item) 67		UID (fetch item) 67
	UID (fetch result) 95		UID (fetch result) 94
	UID <sequence set> (search key) 63		UID <sequence set> (search key) 62
	UIDNEXT (response code) 80		UIDNEXT (response code) 79
	UIDNEXT (status item) 51		UIDNEXT (status item) 50
	UIDNOTSTICKY (response code) 80		UIDNOTSTICKY (response code) 79
	UIDVALIDITY (response code) 80		UIDVALIDITY (response code) 79
	UIDVALIDITY (status item) 51		UIDVALIDITY (status item) 50
	UNANSWERED (search key) 63		UNANSWERED (search key) 62
	UNAVAILABLE (response code) 80		UNAVAILABLE (response code) 79
	UNDELETED (search key) 63		UNDELETED (search key) 62
	UNDRAFT (search key) 63		UNDRAFT (search key) 62
	UNFLAGGED (search key) 63		UNFLAGGED (search key) 62
	UNKEYWORD <flag> (search key) 63		UNKEYWORD <flag> (search key) 62
	UNSEEN (response code) 80		UNSEEN (response code) 79
	UNSEEN (search key) 63		UNSEEN (search key) 62
	UNSEEN (status item) 52		UNSEEN (status item) 51
	UNSELECT (command) 58		UNSELECT (command) 57
	UNSUBSCRIBE (command) 42		UNSUBSCRIBE (command) 41
	Unique Identifier (UID) (message attribute) 9		Unique Identifier (UID) (message attribute) 9
	X		X
	X<atom> (command) 72		X<atom> (command) 71
	[		[
	[RFC-5322] Size (message attribute) 13		[RFC-5322] Size (message attribute) 13
	\		\
	\All (mailbox name attribute) 85		\All (mailbox name attribute) 84
	\Answered (system flag) 11		\Answered (system flag) 11
	\Archive (mailbox name attribute) 85		\Archive (mailbox name attribute) 84
	\Deleted (system flag) 11		\Deleted (system flag) 11
	\Draft (system flag) 12		\Draft (system flag) 12
	\Drafts (mailbox name attribute) 86		\Drafts (mailbox name attribute) 85
	\Flagged (mailbox name attribute) 86		\Flagged (mailbox name attribute) 85
	\Flagged (system flag) 11		\Flagged (system flag) 11
	\HasChildren (mailbox name attribute) 84		\HasChildren (mailbox name attribute) 83
	\HasNoChildren (mailbox name attribute) 85		\HasNoChildren (mailbox name attribute) 84
	\Junk (mailbox name attribute) 86		\Junk (mailbox name attribute) 85
	\Marked (mailbox name attribute) 85		\Marked (mailbox name attribute) 84
	\Noinferiors (mailbox name attribute) 84		\Noinferiors (mailbox name attribute) 83
	\Noselect (mailbox name attribute) 84		\Noselect (mailbox name attribute) 83
	\Recent (system flag) 12		\Recent (system flag) 12
	\Seen (system flag) 11		\Seen (system flag) 11
	\Sent (mailbox name attribute) 86		\Sent (mailbox name attribute) 85
	\Trash (mailbox name attribute) 86		\Trash (mailbox name attribute) 85
	\Unmarked (mailbox name attribute) 85		\Unmarked (mailbox name attribute) 84
	Author's Address		Authors' Addresses
	Alexey Melnikov (editor)		Alexey Melnikov (editor)
	Isode Ltd		Isode Ltd
	14 Castle Mews		14 Castle Mews
	Hampton, Middlesex TW12 2NP		Hampton, Middlesex TW12 2NP
	UK		UK
	Email: Alexey.Melnikov@isode.com		Email: Alexey.Melnikov@isode.com
			Barry Leiba (editor)
			Huawei Technologies
			Phone: +1 646 827 0648
			Email: barryleiba@computer.org
			URI: http://internetmessagingtechnology.org/
End of changes. 87 change blocks.
	418 lines changed or deleted		515 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/