draft-ietf-extra-imap4rev2-21.txt   draft-ietf-extra-imap4rev2-22.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) B. Leiba, Ed. Obsoletes: 3501 (if approved) B. Leiba, Ed.
Intended status: Standards Track Futurewei Technologies Intended status: Standards Track Futurewei Technologies
Expires: May 27, 2021 November 23, 2020 Expires: July 4, 2021 December 31, 2020
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-21 draft-ietf-extra-imap4rev2-22
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 48 skipping to change at page 1, line 48
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 May 27, 2021. This Internet-Draft will expire on July 4, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 129, line 36 skipping to change at page 129, line 36
; the extended LIST command. ; the extended LIST command.
child-mbox-flag = "\HasChildren" / "\HasNoChildren" child-mbox-flag = "\HasChildren" / "\HasNoChildren"
; attributes for CHILDREN return option, at most one ; attributes for CHILDREN return option, at most one
; possible per LIST response ; possible per LIST response
command = tag SP (command-any / command-auth / command-nonauth / command = tag SP (command-any / command-auth / command-nonauth /
command-select) CRLF command-select) CRLF
; Modal based on state ; Modal based on state
command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / enable / x-command command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
; Valid in all states ; Valid in all states
command-auth = append / create / delete / examine / list / command-auth = append / create / delete / enable / examine / list /
Namespace-Command / Namespace-Command /
rename / select / status / subscribe / unsubscribe / rename / select / status / subscribe / unsubscribe /
idle idle
; Valid only in Authenticated or Selected state ; Valid only in Authenticated or Selected state
command-nonauth = login / authenticate / "STARTTLS" command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state ; Valid only when in Not Authenticated state
command-select = "CLOSE" / "UNSELECT" / "EXPUNGE" / copy / command-select = "CLOSE" / "UNSELECT" / "EXPUNGE" / copy /
move / fetch / store / search / uid move / fetch / store / search / uid
skipping to change at page 155, line 35 skipping to change at page 155, line 35
IMAP4rev2 increases allowed body part and message sizes that servers IMAP4rev2 increases allowed body part and message sizes that servers
can support from 32 to 63 bits. Server implementations don't have to can support from 32 to 63 bits. Server implementations don't have to
support 63 bit long body parts/message sizes, however client support 63 bit long body parts/message sizes, however client
implementations have to expect them. implementations have to expect them.
As IMAP4rev1 didn't support 63 bit long body part/message sizes, As IMAP4rev1 didn't support 63 bit long body part/message sizes,
there is an interoperability issue exposed by 63 bit capable servers there is an interoperability issue exposed by 63 bit capable servers
that are accessible by both IMAP4rev1 and IMAP4rev2 email clients. that are accessible by both IMAP4rev1 and IMAP4rev2 email clients.
As IMAP4rev1 would be unable to retrieve full content of messages As IMAP4rev1 would be unable to retrieve full content of messages
bigger than 4Gb, it is RECOMMENDED that such servers hide messages bigger than 4Gb, such servers either need to replace messages bigger
bigger than 4Gb from IMAP4rev1 clients. that 4Gb with messages under 4Gb or hide them from IMAP4rev1 clients.
This document doesn't prescribe any implementation strategy to
For example, image that a mailbox has 3 messages with UIDs 1, 17, 21. address this issue.
These messages have the following sizes (respectively): 32Kb, 5Gb,
60Mb. When such mailbox is accessed by an IMAP4rev2 client that
issued "ENABLE IMAP4rev2", it will see all 3 messages. When such
mailbox is accessed by an IMAP4rev1 client, it will only see messages
with UIDs 1 and 21.
Appendix E. Changes from RFC 3501 / IMAP4rev1 Appendix E. Changes from RFC 3501 / IMAP4rev1
Below is the summary of changes since RFC 3501: Below is the summary of changes since RFC 3501:
1. Support for 64bit message and body part sizes. 1. Support for 64bit message and body part sizes.
2. Folded in IMAP NAMESPACE (RFC 2342), UNSELECT (RFC 3691), 2. Folded in IMAP NAMESPACE (RFC 2342), UNSELECT (RFC 3691),
UIDPLUS (RFC 4315), ESEARCH (RFC 4731), SEARCHRES (RFC 5182), UIDPLUS (RFC 4315), ESEARCH (RFC 4731), SEARCHRES (RFC 5182),
ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC 4959), LIST- ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC 4959), LIST-
skipping to change at page 158, line 25 skipping to change at page 158, line 22
5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Sirainen), RFC 6154 (by 5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Sirainen), RFC 6154 (by
Jamie Nicolson), RFC 8438 (by Stephan Bosch) so work done by authors/ Jamie Nicolson), RFC 8438 (by Stephan Bosch) so work done by authors/
editors of these documents is appreciated. Note that editors of this editors of these documents is appreciated. Note that editors of this
document were redacted from the above list. document were redacted from the above list.
The CHILDREN return option was originally proposed by Mike Gahrns and The CHILDREN return option was originally proposed by Mike Gahrns and
Raymond Cheng in [RFC3348]. Most of the information in Raymond Cheng in [RFC3348]. Most of the information in
Section 6.3.9.5 is taken directly from their original specification Section 6.3.9.5 is taken directly from their original specification
[RFC3348]. [RFC3348].
Thank you to Damian Poddebniak for pointing out that the ENABLE
command should be a member of "command-auth" and not "command-any"
ABNF production.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$Junk (predefined flag) 12 $Junk (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
$NotJunk (predefined flag) 12 $NotJunk (predefined flag) 12
$Phishing (predefined flag) 13 $Phishing (predefined flag) 13
+ +
 End of changes. 7 change blocks. 
14 lines changed or deleted 13 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/