< draft-melnikov-imap4rev2-07.txt   draft-melnikov-imap4rev2-08.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) March 4, 2018 Obsoletes: 3501 (if approved) May 29, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: September 5, 2018 Expires: November 30, 2018
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-melnikov-imap4rev2-07.txt draft-melnikov-imap4rev2-08.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 September 5, 2018. This Internet-Draft will expire on November 30, 2018.
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 2, line 46 skipping to change at page 2, line 46
1.2. Conventions Used in This Document . . . . . . . . . . . . 5 1.2. Conventions Used in This Document . . . . . . . . . . . . 5
1.3. Special Notes to Implementors . . . . . . . . . . . . . . 6 1.3. Special Notes to Implementors . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Link Level . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Link Level . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Commands and Responses . . . . . . . . . . . . . . . . . 7 2.2. Commands and Responses . . . . . . . . . . . . . . . . . 7
2.2.1. Client Protocol Sender and Server Protocol Receiver . 7 2.2.1. Client Protocol Sender and Server Protocol Receiver . 7
2.2.2. Server Protocol Sender and Client Protocol Receiver . 8 2.2.2. Server Protocol Sender and Client Protocol Receiver . 8
2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9 2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9
2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9 2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9
2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11 2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11
2.3.3. Internal Date Message Attribute . . . . . . . . . . . 12 2.3.3. Internal Date Message Attribute . . . . . . . . . . . 13
2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 13 2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 13
2.3.5. Envelope Structure Message Attribute . . . . . . . . 13 2.3.5. Envelope Structure Message Attribute . . . . . . . . 13
2.3.6. Body Structure Message Attribute . . . . . . . . . . 13 2.3.6. Body Structure Message Attribute . . . . . . . . . . 13
2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 13
3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 13 3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 13
3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 13 3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14
3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . 17
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 4, line 43 skipping to change at page 4, line 43
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 91 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 91
7.5. Server Responses - Command Continuation Request . . . . . 96 7.5. Server Responses - Command Continuation Request . . . . . 96
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 96 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 96
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 98 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 . . . . . . . . . . . . 112
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 112 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 112
11.3. Other Security Considerations . . . . . . . . . . . . . 112 11.3. Other Security Considerations . . . . . . . . . . . . . 112
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113
12.1. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 113 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 113
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 114
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
13.1. Normative References . . . . . . . . . . . . . . . . . . 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 114
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 . . . . . . . 117 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 118
Appendix B. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 118 Appendix B. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 118
Appendix C. Acknowledgement . . . . . . . . . . . . . . . . . . 119 Appendix C. Acknowledgement . . . . . . . . . . . . . . . . . . 119
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 124
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
skipping to change at page 11, line 41 skipping to change at page 11, line 41
messages which have greater UIDs. messages which have greater UIDs.
2.3.2. Flags Message Attribute 2.3.2. Flags Message Attribute
A list of zero or more named tokens associated with the message. A A list of zero or more named tokens associated with the message. A
flag is set by its addition to this list, and is cleared by its flag is set by its addition to this list, and is cleared by its
removal. There are two types of flags in IMAP4rev2. A flag of removal. There are two types of flags in IMAP4rev2. A flag of
either type can be permanent or session-only. either type can be permanent or session-only.
A system flag is a flag name that is pre-defined in this A system flag is a flag name that is pre-defined in this
specification. All system flags begin with "\". Certain system specification and begin with "\". Certain system flags (\Deleted and
flags (\Deleted and \Seen) have special semantics described \Seen) have special semantics described elsewhere. The currently-
elsewhere. The currently-defined system flags are: defined system flags are:
\Seen Message has been read \Seen Message has been read
\Answered Message has been answered \Answered Message has been answered
\Flagged Message is "flagged" for urgent/special attention \Flagged Message is "flagged" for urgent/special attention
\Deleted Message is "deleted" for removal by later EXPUNGE \Deleted Message is "deleted" for removal by later EXPUNGE
\Draft Message has not completed composition (marked as a draft). \Draft Message has not completed composition (marked as a draft).
skipping to change at page 12, line 24 skipping to change at page 12, line 24
message SHOULD be considered recent. message SHOULD be considered recent.
If multiple connections have the same mailbox selected If multiple connections have the same mailbox selected
simultaneously, it is undefined which of these connections will simultaneously, it is undefined which of these connections will
see newly-arrived messages with \Recent set and which will see it see newly-arrived messages with \Recent set and which will see it
without \Recent set. without \Recent set.
A keyword is defined by the server implementation. Keywords do not A keyword is defined by the server implementation. Keywords do not
begin with "\". Servers MAY permit the client to define new keywords begin with "\". Servers MAY permit the client to define new keywords
in the mailbox (see the description of the PERMANENTFLAGS response in the mailbox (see the description of the PERMANENTFLAGS response
code for more information). code for more information). Some keywords that start with "$" are
also defined in this specification.
This document defines several keywords that were not originally
defined in RFC 3501, but which were found to be useful by client
implementations. These keywords SHOULD be supported (i.e. allowed in
APPEND, COPY and SEARCH commands) by server implementations:
\Forwarded Message has been forwarded to another email address,
embedded within or attached to a new message. An email client
sets this keyword when it successfully forwards the message to
another email address. Typical usage of this keyword is to show a
different (or additional) icon for a message that has been
forwarded. Once set, the flag SHOULD NOT be cleared.
$MDNSent Message Disposition Notification was generated and sent for
this message.
A flag can be permanent or session-only on a per-flag basis. A flag can be permanent or session-only on a per-flag basis.
Permanent flags are those which the client can add or remove from the Permanent flags are those which the client can add or remove from the
message flags permanently; that is, concurrent and subsequent message flags permanently; that is, concurrent and subsequent
sessions will see any change in permanent flags. Changes to session sessions will see any change in permanent flags. Changes to session
flags are valid only in that session. flags are valid only in that session.
Note: The \Recent system flag is a special case of a session flag. Note: The \Recent system flag is a special case of a session flag.
\Recent can not be used as an argument in a STORE or APPEND \Recent can not be used as an argument in a STORE or APPEND
command, and thus can not be changed at all. command, and thus can not be changed at all.
skipping to change at page 105, line 43 skipping to change at page 105, line 43
; The third Namespace is the Shared Namespace(s) ; The third Namespace is the Shared Namespace(s)
nil = "NIL" nil = "NIL"
nstring = string / nil nstring = string / nil
number = 1*DIGIT number = 1*DIGIT
; Unsigned 32-bit integer ; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296) ; (0 <= n < 4,294,967,296)
number64 = 1*DIGIT
; Unsigned 63-bit integer
; (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
skipping to change at page 108, line 31 skipping to change at page 108, line 35
search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT" / search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT" /
search-ret-opt-ext search-ret-opt-ext
; conforms to generic search-ret-opt-ext ; conforms to generic search-ret-opt-ext
; syntax ; syntax
search-ret-opt-ext = search-modifier-name [SP search-mod-params] search-ret-opt-ext = search-modifier-name [SP search-mod-params]
search-return-value = tagged-ext-val search-return-value = tagged-ext-val
; Data for the returned search option. ; Data for the returned search option.
; A single "nz-number"/"number" 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 part
skipping to change at page 110, line 40 skipping to change at page 110, line 45
"(" tagged-ext-comp ")" "(" tagged-ext-comp ")"
;; Extensions that follow this general ;; Extensions that follow this general
;; syntax should use nstring instead of ;; syntax should use nstring instead of
;; astring when appropriate in the context ;; astring when appropriate in the context
;; of the extension. ;; of the extension.
;; Note that a message set or a "number" ;; Note that a message set or a "number"
;; can always be represented as an "atom". ;; can always be represented as an "atom".
;; An URL should be represented as ;; An URL should be represented as
;; a "quoted" string. ;; a "quoted" string.
tagged-ext-simple = sequence-set / number tagged-ext-simple = sequence-set / number / number64
tagged-ext-val = tagged-ext-simple / tagged-ext-val = tagged-ext-simple /
"(" [tagged-ext-comp] ")" "(" [tagged-ext-comp] ")"
text = 1*TEXT-CHAR text = 1*TEXT-CHAR
TEXT-CHAR = <any CHAR except CR and LF> TEXT-CHAR = <any CHAR except CR and LF>
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; Hours minutes seconds ; Hours minutes seconds
uid = "UID" SP (copy / fetch / search / store / uid-expunge) uid = "UID" SP (copy / fetch / search / store / uid-expunge)
; Unique identifiers used instead of message ; Unique identifiers used instead of message
; sequence numbers ; sequence numbers
uid-expunge = "EXPUNGE" SP sequence-set uid-expunge = "EXPUNGE" SP sequence-set
; Unique identifiers used instead of message ; Unique identifiers used instead of message
; sequence numbers ; sequence numbers
skipping to change at page 113, line 30 skipping to change at page 113, line 30
that the user name, as opposed to the password, is invalid. that the user name, as opposed to the password, is invalid.
A server SHOULD have mechanisms in place to limit or delay failed A server SHOULD have mechanisms in place to limit or delay failed
AUTHENTICATE/LOGIN attempts. AUTHENTICATE/LOGIN attempts.
Additional security considerations are discussed in the section Additional security considerations are discussed in the section
discussing the AUTHENTICATE and LOGIN commands. discussing the AUTHENTICATE and LOGIN commands.
12. IANA Considerations 12. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IANA is requested to update "Service Names and Transport Protocol
IESG approved experimental RFC. The registry is currently located Port Numbers" registry as follows:
at: http://www.iana.org/assignments/imap4-capabilities
1. Registration for TCP "imap" port 143 should be updated to point
to this document and RFC 3501.
2. Registration for TCP "imaps" port 993 should be updated to point
to this document and RFC 3501.
3. Both UDP port 143 and UDP port 993 should be marked as "Reserved"
in the registry.
Additional IANA actions are specified in subsection of this section.
12.1. Updates to IMAP4 Capabilities registry
IMAP4 capabilities are registered by publishing a standards track or
IESG approved informational or experimental RFC. The registry is
currently located at: http://www.iana.org/assignments/
imap4-capabilities
As this specification revises the STARTTLS and LOGINDISABLED As this specification revises the STARTTLS and LOGINDISABLED
extensions previously defined in [IMAP-TLS], IANA is requested to extensions previously defined in [IMAP-TLS], IANA is requested to
update the registry accordingly. update registry entries for these 2 extensions to point to this
document.
12.1. GSSAPI/SASL service name 12.2. GSSAPI/SASL service name
GSSAPI/Kerberos/SASL service names are registered by publishing a GSSAPI/Kerberos/SASL service names are registered by publishing a
standards track or IESG approved experimental RFC. The registry is standards track or IESG approved experimental RFC. The registry is
currently located at: http://www.iana.org/assignments/gssapi-service- currently located at: http://www.iana.org/assignments/gssapi-service-
names names
IANA is requested to update the "imap" service name previously IANA is requested to update the "imap" service name previously
registered in RFC 3501, to point to this document. registered in RFC 3501, to point to this document.
13. References 13. References
skipping to change at page 118, line 15 skipping to change at page 118, line 27
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 "ENABLE IMAP4rev2" command.
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). NAMESPACE (done), SASL-IR (done).
2. Add CLOSED response code (from CONDSTORE) - done 2. Add CLOSED response code (from CONDSTORE) - done
3. Require support for $MDNSent and $Forwarded IMAP keywords. 3. Add support for $MDNSent and $Forwarded IMAP keywords - done.
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 + deprecate LSUB (replace it with LIST EXTENDED syntax + deprecate LSUB (replace it with LIST
\Subscribed) - multiple list patterns, STATUS-in-LIST, Unique \Subscribed) - multiple list patterns, STATUS-in-LIST, Unique
mailstore IDs for messages (a la Gmail and Cyrus) - if there is mailstore IDs for messages (a la Gmail and Cyrus) - if there is
skipping to change at page 118, line 46 skipping to change at page 119, line 10
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.
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:
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.
2. Added CLOSED response code from RFC 7162. 2. Added CLOSED response code from RFC 7162.
3. Updated to use modern TLS-related recommendations as per RFC 3. Updated to use modern TLS-related recommendations as per RFC
8314, RFC 7817, RFC 7525. 8314, RFC 7817, RFC 7525.
4. For future extensibility extended ABNF for tagged-ext-simple to
allow for bare number64.
5. Add SHOULD level requirement on IMAP servers to support $MDNSent
and $Forwarded keywords.
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.
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
$MDNSent (predefined flag) 12
+ +
+FLAGS <flag list> 68 +FLAGS <flag list> 68
+FLAGS.SILENT <flag list> 68 +FLAGS.SILENT <flag list> 68
- -
-FLAGS <flag list> 68 -FLAGS <flag list> 68
-FLAGS.SILENT <flag list> 68 -FLAGS.SILENT <flag list> 68
A A
ALERT (response code) 74 ALERT (response code) 74
skipping to change at page 121, line 21 skipping to change at page 121, line 44
HEADER (part specifier) 65 HEADER (part specifier) 65
HEADER <field-name> <string> (search key) 61 HEADER <field-name> <string> (search key) 61
HEADER.FIELDS (part specifier) 65 HEADER.FIELDS (part specifier) 65
HEADER.FIELDS.NOT (part specifier) 65 HEADER.FIELDS.NOT (part specifier) 65
I I
IDLE (command) 54 IDLE (command) 54
INTERNALDATE (fetch item) 67 INTERNALDATE (fetch item) 67
INTERNALDATE (fetch result) 95 INTERNALDATE (fetch result) 95
INUSE (response code) 77 INUSE (response code) 77
Internal Date (message attribute) 12 Internal Date (message attribute) 13
K K
KEYWORD <flag> (search key) 61 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) 62
LIMIT (response code) 77 LIMIT (response code) 77
LIST (command) 42 LIST (command) 42
LIST (response) 84 LIST (response) 84
skipping to change at page 122, line 22 skipping to change at page 122, line 45
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) 62
OVERQUOTA (response code) 78 OVERQUOTA (response code) 78
P P
PARSE (response code) 78 PARSE (response code) 78
PERMANENTFLAGS (response code) 78 PERMANENTFLAGS (response code) 78
PREAUTH (response) 82 PREAUTH (response) 82
PRIVACYREQUIRED (response code) 79 PRIVACYREQUIRED (response code) 79
Permanent Flag (class of flag) 12 Permanent Flag (class of flag) 12
Predefined keywords 12
R R
READ-ONLY (response code) 79 READ-ONLY (response code) 79
READ-WRITE (response code) 79 READ-WRITE (response code) 79
RECENT (search key) 62 RECENT (search key) 62
RECENT (status item) 51 RECENT (status item) 51
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 39 RENAME (command) 39
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822 (fetch item) 67 RFC822 (fetch item) 67
 End of changes. 26 change blocks. 
25 lines changed or deleted 75 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/