Calendar Access Protocol (CAP)
RFC 4324
| Document | Type |
RFC
- Experimental
(December 2005)
Was
draft-royer-calsch-cap
(individual in gen area)
|
|
|---|---|---|---|
| Authors | George Babics , Steve Mansour , Doug Royer | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| IESG | Responsible AD | Ted Hardie | |
| Send notices to | (None) |
RFC 4324
Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd
Obsoletes: 3501 (if approved) B. Leiba, Ed.
Intended status: Standards Track Futurewei Technologies
Expires: January 30, 2021 July 29, 2020
Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-17
Abstract
The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev2 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local
folders. IMAP4rev2 also provides the capability for an offline
client to resynchronize with the server.
IMAP4rev2 includes operations for creating, deleting, and renaming
mailboxes, checking for new messages, permanently removing messages,
setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing,
searching, and selective fetching of message attributes, texts, and
portions thereof. Messages in IMAP4rev2 are accessed by the use of
numbers. These numbers are either message sequence numbers or unique
identifiers.
IMAP4rev2 does not specify a means of posting mail; this function is
handled by a mail submission protocol such as RFC 6409.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 30, 2021.
Melnikov & Leiba Expires January 30, 2021 [Page 1]
Internet-Draft IMAP4rev2 July 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. How to Read This Document . . . . . . . . . . . . . . . . . . 5
1.1. Organization of This Document . . . . . . . . . . . . . . 5
1.2. Conventions Used in This Document . . . . . . . . . . . . 5
1.3. Special Notes to Implementors . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Link Level . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Commands and Responses . . . . . . . . . . . . . . . . . 7
2.2.1. Client Protocol Sender and Server Protocol Receiver . 7
2.2.2. Server Protocol Sender and Client Protocol Receiver . 8
2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9
2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9
2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11
2.3.3. Internal Date Message Attribute . . . . . . . . . . . 13
2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 14
2.3.5. Envelope Structure Message Attribute . . . . . . . . 14
2.3.6. Body Structure Message Attribute . . . . . . . . . . 14
2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 14
3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 14
3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14
Melnikov & Leiba Expires January 30, 2021 [Page 2]
Internet-Draft IMAP4rev2 July 2020
3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14
3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 15
3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 15
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 17
4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Operational Considerations . . . . . . . . . . . . . . . . . 20
5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 21
5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 21
5.2. Mailbox Size and Message Status Updates . . . . . . . . . 23
5.3. Response when no Command in Progress . . . . . . . . . . 23
5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 23
5.5. Multiple Commands in Progress (Command Pipelining) . . . 23
6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Client Commands - Any State . . . . . . . . . . . . . . . 25
6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 25
6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 26
6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 27
6.2. Client Commands - Not Authenticated State . . . . . . . . 27
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 29
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 32
6.3. Client Commands - Authenticated State . . . . . . . . . . 33
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 33
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 39
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 41
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 43
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 44
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 44
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 62
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 67
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 68
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 71
6.4. Client Commands - Selected State . . . . . . . . . . . . 73
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 73
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 74
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 74
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 75
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 87
Melnikov & Leiba Expires January 30, 2021 [Page 3]
Internet-Draft IMAP4rev2 July 2020
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 91
6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 93
6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 94
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 95
6.5. Client Commands - Experimental/Expansion . . . . . . . . 97
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 97
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 98
7.1. Server Responses - Status Responses . . . . . . . . . . . 99
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 107
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 107
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 108
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 108
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 108
7.2. Server Responses - Server and Mailbox Status . . . . . . 109
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 109
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 109
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 110
7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 114
7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 115
7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 115
7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 115
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 116
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 116
7.4. Server Responses - Message Status . . . . . . . . . . . . 116
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 116
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 117
7.5. Server Responses - Command Continuation Request . . . . . 123
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 124
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 125
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 142
11. Security Considerations . . . . . . . . . . . . . . . . . . . 142
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 142
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 143
11.3. LIST command and Other Users' namespace . . . . . . . . 143
11.4. Other Security Considerations . . . . . . . . . . . . . 143
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 145
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 145
12.3. LIST Selection Options, LIST Return Options, LIST
extended data items . . . . . . . . . . . . . . . . . . 145
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 145
13.1. Normative References . . . . . . . . . . . . . . . . . . 145
13.2. Informative References (related protocols) . . . . . . . 149
13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 150
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 151
A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 152
Melnikov & Leiba Expires January 30, 2021 [Page 4]
Internet-Draft IMAP4rev2 July 2020
Appendix B. Backward compatibility with BINARY extension . . . . 153
Appendix C. Backward compatibility with LIST-EXTENDED extension 153
Appendix D. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 154
Appendix E. Acknowledgement . . . . . . . . . . . . . . . . . . 156
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162
1. How to Read This Document
1.1. Organization of This Document
This document is written from the point of view of the implementor of
an IMAP4rev2 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev2
operates.
Sections 6, 7, and 9 describe the IMAP commands, responses, and
syntax, respectively. The relationships among these are such that it
is almost impossible to understand any of them separately. In
particular, do not attempt to deduce command syntax from the command
section alone; instead refer to the Formal Syntax section.
1.2. Conventions Used in This Document
"Conventions" are basic principles or procedures. Document
conventions are noted in this section.
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The word "can" (not "may") is used to refer to a possible
circumstance or situation, as opposed to an optional facility of the
protocol.
"User" is used to refer to a human user, whereas "client" refers to
the software being run by the user.
"Connection" refers to the entire sequence of client/server
interaction from the initial establishment of the network connection
until its termination.
Melnikov & Leiba Expires January 30, 2021 [Page 5]
Internet-Draft IMAP4rev2 July 2020
"Session" refers to the sequence of client/server interaction from
the time that a mailbox is selected (SELECT or EXAMINE command) until
the time that selection ends (SELECT or EXAMINE of another mailbox,
CLOSE command, UNSELECT command, or connection termination).
Characters are 8-bit UTF-8 (of which 7-bit US-ASCII is a subset)
unless otherwise specified. Other character sets are indicated using
a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET].
CHARSETs have important additional semantics in addition to defining
character set; refer to these documents for more detail.
There are several protocol conventions in IMAP. These refer to
aspects of the specification which are not strictly part of the IMAP
protocol, but reflect generally-accepted practice. Implementations
need to be aware of these conventions, and avoid conflicts whether or
not they implement the convention. For example, "&" may not be used
as a hierarchy delimiter since it conflicts with the Mailbox
International Naming Convention, and other uses of "&" in mailbox
names are impacted as well.
1.3. Special Notes to Implementors
Implementors of the IMAP protocol are strongly encouraged to read the
IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
conjunction with this document, to help understand the intricacies of
this protocol and how best to build an interoperable product.
IMAP4rev2 is designed to be upwards compatible from the [IMAP2] and
unpublished IMAP2bis protocols. IMAP4rev2 is largely compatible with
the IMAP4rev1 protocol described in RFC 3501 and the IMAP4 protocol
described in RFC 1730; the exception being in certain facilities
added in RFC 1730 that proved problematic and were subsequently
removed. In the course of the evolution of IMAP4rev2, some aspects
in the earlier protocols have become obsolete. Obsolete commands,
responses, and data formats which an IMAP4rev2 implementation can
encounter when used with an earlier implementation are described in
Appendix D and [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT]. A full
discussion of compatibility issues with rare (and presumed extinct)
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest.
IMAP was originally developed for the older [RFC-822] standard, and
as a consequence several fetch items in IMAP incorporate "RFC822" in
their name. In all cases, "RFC822" should be interpreted as a
reference to the updated [RFC-5322] standard.
Melnikov & Leiba Expires January 30, 2021 [Page 6]
Internet-Draft IMAP4rev2 July 2020
2. Protocol Overview
2.1. Link Level
The IMAP4rev2 protocol assumes a reliable data stream such as that
provided by TCP. When TCP is used, an IMAP4rev2 server listens on
port 143 or port 993 (IMAP-over-TLS).
2.2. Commands and Responses
An IMAP4rev2 connection consists of the establishment of a client/
server network connection, an initial greeting from the server, and
client/server interactions. These client/server interactions consist
of a client command, server data, and a server completion result
response.
All interactions transmitted by client and server are in the form of
lines, that is, strings that end with a CRLF. The protocol receiver
of an IMAP4rev2 client or server is either reading a line, or is
reading a sequence of octets with a known count followed by a line.
2.2.1. Client Protocol Sender and Server Protocol Receiver
The client command begins an operation. Each client command is
prefixed with an identifier (typically a short alphanumeric string,
e.g., A0001, A0002, etc.) called a "tag". A different tag is
generated by the client for each command. (More formally: the client
SHOULD generate a unique tag for every command, but a server MUST
accept tag reuse.)
Clients MUST follow the syntax outlined in this specification
strictly. It is a syntax error to send a command with missing or
extraneous spaces or arguments.
There are two cases in which a line from the client does not
represent a complete command. In one case, a command argument is
quoted with an octet count (see the description of literal in String
under Data Formats); in the other case, the command arguments require
server feedback (see the AUTHENTICATE command). In either case, the
server sends a command continuation request response if it is ready
for the octets (if appropriate) and the remainder of the command.
This response is prefixed with the token "+", and
"DEFAULTOWNER".
Description: This property is used in the "VCALSTORE" component to
specify the "CARID" value of the "VCAR" components that MUST be
copied into now "VAGENDA" components at creation time by the CS.
All "DEFAULT-VCAR" values must have "VCARS" components stored in
the "VCALSTORE".
Formal Definition: The property is defined by the following notation:
defautl-vcars = "DEFAULT-VCARS" other-params ":" text
*( "," text ) CRLF
Example: The following is an example of this property:
DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY,
UPDATEPARTSTATUS,DEFAULTOWNER
8.15. DENY Property
Property Name: DENY
Purpose: This property identifies the UPN(s) being denied access in
the "VRIGHT" component.
Value Type: UPN-FILTER
Property Parameters: Non-standard property parameters can be
specified on this property.
Royer, et al. Experimental [Page 62]
RFC 4324 Calendar Access Protocol December 2005
Conformance: This property can be specified in "VRIGHT" components.
Description: This property is used in the "VRIGHT" component to
define the CU or UG being denied access.
Formal Definition: The property is defined by the following notation:
deny = "DENY" other-params ":" upn-filter CRLF
Example: The following are examples of this property:
DENY:*
DENY:bob@example.com
8.16. EXPAND property
Property Name: EXPAND
Purpose: This property is used to notify the CS whether to expand any
component with recurrence rules into multiple instances, in a
query reply.
Value Type: BOOLEAN
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in "VQUERY" components.
Description: If a CUA wishes to see all of the instances of a
recurring component, the CUA sets EXPAND=TRUE in the "VQUERY"
component. If not specified, the default is "FALSE". Note that
if the CS has its "RECUR-EXPAND" CS property value set to "FALSE",
then the "EXPAND" property will be ignored and the result will be
as if the "EXPAND" value was set to "FALSE". The results will be
bounded by any date range or other limits in the query.
Formal Definition: The property is defined by the following notation:
expand = "EXPAND" other-params ":" ("TRUE" / "FALSE") CRLF
Example: The following are examples of this property:
EXPAND:FALSE
EXPAND:TRUE
Royer, et al. Experimental [Page 63]
RFC 4324 Calendar Access Protocol December 2005
8.17. GRANT Property
Property Name: GRANT
Purpose: This property identifies the UPN(s) being granted access in
the "VRIGHT" component.
Value Type: UPN-FILTER
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in "VRIGHT" calendar
components.
Description: This property is used in the "VRIGHT" component to
specify the CU or UG being granted access.
Formal Definition: The property is defined by the following notation:
grant = "GRANT" other-params ":" upn-filter CRLF
Example: The following are examples of this property:
GRANT:*
GRANT:bob@example.com
8.18. ITIP-VERSION Property
Property Name: ITIP-VERSION
Purpose: This property specifies the version of ITIP supported.
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property is specified in the "VREPLY" component
that is sent in response to a "GET-CAPABILITY" command.
Description: This specifies the version of ITIP that the endpoint
supports. The list is a comma-separated list of supported RFC
numbers. The list MUST contain at least 2446, which is [iTIP]
Formal Definition: The property is defined by the following notation:
Royer, et al. Experimental [Page 64]
RFC 4324 Calendar Access Protocol December 2005
itip-version = "ITIP-VERSION" other-params ":" text CRLF
Example: The following are examples of this property:
ITIP-VERSION:2446
8.19. MAX-COMP-SIZE Property
Property Name: MAX-COMP-SIZE
Purpose: This property specifies the largest size of any object
accepted.
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property is specified in the "VREPLY" component
that is sent in response to a "GET-CAPABILITY" command.
Description: A positive integer value that specifies the size of the
largest iCalendar object that can be accepted in octets. Objects
larger than this will be rejected. A value of zero (0) means no
limit. This is also the maximum value of any [BEEP] payload that
will be accepted or sent.
Formal Definition: The property is defined by the following notation:
max-comp-size = "MAX-COMP-SIZE" other-params ":" posint0 CRLF
Example: The following are examples of this property:
MAX-COMP-SIZE:1024
8.20. MAXDATE Property
Property Name: MAXDATE
Purpose: This property specifies the date/time in the future, beyond
which the CS or CUA cannot represent.
Value Type: DATE-TIME
Property Parameters: Non-standard property parameters can be
specified on this property.
Royer, et al. Experimental [Page 65]
RFC 4324 Calendar Access Protocol December 2005
Conformance: The property can be specified in the "VCALSTORE"
component.
Description: The date and time MUST be a UTC value and end with 'Z'.
Formal Definition: The property is defined by the following notation:
maxdate = "MAXDATE" other-params ":" date-time CRLF
Example: The following is an example of this property:
MAXDATE:20990101T000000Z
8.21. MINDATE Property
Property Name: MINDATE
Purpose: This property specifies the date/time in the past, prior to
which the server cannot represent.
Value Type: DATE-TIME
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: The property can be specified in the "VCALSTORE"
component.
Description: The date and time MUST be a UTC value and end with 'Z'.
Formal Definition: The property is defined by the following notation:
mindate = "MINDATE" other-params ":" date-time CRLF
date-time = ; As defined in [iCAL].
Example: The following is an example of this property:
MINDATE:19710101T000000Z
8.22. MULTIPART Property
Property Name: MULTIPART
Purpose: This property provides a comma-separated list of supported
MIME multipart types supported by the sender.
Royer, et al. Experimental [Page 66]
RFC 4324 Calendar Access Protocol December 2005
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property is specified in the "VREPLY" component
that is sent in response to a "GET-CAPABILITY" command.
Description: This property is used in the in the "GET-CAPABILITY"
command reply to indicate the MIME multipart types supported. A
CS and CUA SHOULD support all registered MIME multipart types.
Formal Definition: The property is defined by the following notation:
multipart = "MULTIPART" other-params ":" text *( "," text) CRLF
Example: The following is an example of this property:
MULTIPART:related,alternate,mixed
8.23. NAME Property
Property Name: NAME
Purpose: This property provides a localizable display name for a
component.
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in a component.
Description: This property is used in the component to specify a
localizable display name. If more than one "NAME" properties are
in a component, then they MUST have unique "LANG" parameters. If
the "LANG" parameter is not supplied, then it defaults to the
"VAGENDA" component's "DEFAULT-LOCALE" first value. If the
component is a "VAGENDA", then the default value is the "VAGENDA"s
component's "DEFAULT-LOCALE" first value. A "VCALSTORE"
component's "DEFAULT-LOCALE" first value is the default if the
component is stored at the "VCALSTORE" level.
Formal Definition: The property is defined by the following notation:
Royer, et al. Experimental [Page 67]
RFC 4324 Calendar Access Protocol December 2005
name = "NAME" nameparam ":" text CRLF
;
nameparam = other-params [ ";" languageparam ] other-params
;
languageparam = ; As defined in [iCAL].
Example: The following is an example of this property:
NAME:Restrict Guests From Creating VALARMs On VEVENTs
8.24. OWNER Property
Property Name: OWNER
Purpose: The property specifies an owner of the component.
Value Type: UPN
Property Parameters: Non-standard, alternate text representation and
language property parameters can be specified on this property.
Conformance: The property MUST be specified in a "VAGENDA" component.
Description: A multi-instanced property indicating the calendar
owner.
Formal Definition: The property is defined by the following notation:
owner = "OWNER" other-params ":" upn CRLF
Example: The following is an example of this property:
OWNER:jsmith@example.com
OWNER:jdough@example.com
8.25. PERMISSION Property
Property Name: PERMISSION
Purpose: This property defines a permission that is granted or denied
in a "VRIGHT" component.
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in "VRIGHT" components.
Royer, et al. Experimental [Page 68]
RFC 4324 Calendar Access Protocol December 2005
Description: This property is used in the "VRIGHT" component to
define a permission that is granted or denied.
Formal Definition: The property is defined by the following notation:
permission = "PERMISSION" other-params ":" permvalue CRLF
;
permvalue = ( "SEARCH" / "CREATE" / "DELETE"
/ "MODIFY" / "MOVE" / all
/ iana-cmd / x-cmd )
;
all = "*"
;
iana-cmd = ; Any command registered by IANA directly or
; included in an RFC that may be applied as
; a command.
;
x-cmd = ; Any experimental command that starts with
; "x-" or "X-".
Example: The following is an example of this property:
PERMISSION:SEARCH
8.26. QUERY property
Property Name: QUERY
Purpose: Specifies the query for the component.
Value Type: CAL-QUERY
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in "VQUERY" components.
Description: A "QUERY" is used to specify the "CAL-QUERY" (Section
6.1.1 for the query.
Formal Definition: The property is defined by the following notation:
query = "QUERY" other-params ":" cal-query CRLF
Example: The following is an example of this property:
QUERY:SELECT * FROM VEVENT
Royer, et al. Experimental [Page 69]
RFC 4324 Calendar Access Protocol December 2005
8.27. QUERYID property
Property Name: QUERYID
Purpose: Specifies a unique ID for a query in the targeted container.
Value Type: TEXT
Property Parameters: Non-standard property parameters are specified
on this property.
Conformance: This property can be specified in "VQUERY" components.
Description: A "QUERYID" property is used to specify the unique id
for a query. A "QUERYID" property value is unique per container.
Formal Definition: The property is defined by the following notation:
queryid = "QUERYID" other-params ":" text CRLF
Example: The following are examples of this property:
QUERYID:Any Text String
QUERYID:fetchUnProcessed
8.28. QUERY-LEVEL Property
Property Name: QUERY-LEVEL
Purpose: This property specifies the level of query supported.
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: The property can be specified in the "VREPLY" component
in response to a "GET-CAPABILITY" command.
Description: Indicates level of query support. CAL-QL-NONE is for
CS's that allow ITIP methods only to be deposited and nothing
else.
Formal Definition: The property is defined by the following notation:
query-level = "QUERY-LEVEL" other-params
":" ( "CAL-QL-1" / "CAL-QL-NONE") CRLF
Royer, et al. Experimental [Page 70]
RFC 4324 Calendar Access Protocol December 2005
Example: The following is an example of this property:
QUERY-LEVEL:CAL-QL-1
8.29. RECUR-ACCEPTED Property
Property Name: RECUR-ACCEPTED
Purpose: This property specifies if the endpoint supports recurring
instances.
Value Type: BOOLEAN
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: The property can be specified in the "VREPLY" component
in response to a "GET-CAPABILITY" command.
Description: Indicates if recurrence rules are supported. If "FALSE"
then the endpoint cannot process any kind of recurring rules.
Formal Definition: The property is defined by the following notation:
recur-accepted = "RECUR-ACCEPTED" other-params ":" boolean CRLF
Example: The following is an example of this property:
RECUR-ACCEPTED:TRUE
RECUR-ACCEPTED:FALSE
8.30. RECUR-LIMIT Property
Property Name: RECUR-LIMIT
Purpose: This property specifies the maximum number of instances the
endpoint will expand instances at query or storage time.
Value Type: INTEGER
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: The property can be specified in the "VREPLY" component
in response to a "GET-CAPABILITY" command.
Description: For implementations that have the "STORES-EXPANDED"
value set to "TRUE", this value specifies the maximum number of
Royer, et al. Experimental [Page 71]
RFC 4324 Calendar Access Protocol December 2005
instances that will be stored and fetched. For all
implementations, this is the maximum number of instances that will
be returned when the "EXPAND" parameter is specified as "TRUE" and
the results contain an infinite or large number of recurring
instances.
Formal Definition: The property is defined by the following notation:
recur-limit = "RECUR-LIMIT" other-params ":" posint1 CRLF
Example: The following is an example of this property:
RECUR-LIMIT:1000
8.31. RECUR-EXPAND Property
Property Name: RECUR-EXPAND
Purpose: This property specifies if the endpoint can expand
recurrences into multiple objects.
Value Type: BOOLEAN
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: The property can be specified in the "VREPLY" component
in response to a "GET-CAPABILITY" command.
Description: If "TRUE", then the endpoint can expand an object into
multiple instances as defined by its recurrence rules when the
"EXPAND" property is supplied. If "FALSE", then the endpoint
ignores the "EXPAND" property.
Formal Definition: The property is defined by the following notation:
recur-expand = "RECUR-EXPAND" other-params ":" boolean CRLF
Example: The following is an example of this property:
RECUR-EXPAND:TRUE
RECUR-EXPAND:FALSE
8.32. RESTRICTION Property
Property Name: RESTRICTION
Royer, et al. Experimental [Page 72]
RFC 4324 Calendar Access Protocol December 2005
Purpose: This property defines restrictions on the result value of
new or existing components.
Value Type: CAL-QUERY
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in "VRIGHT" components,
but only when the "PERMISSION" property is set to "CREATE",
"MODIFY", or "*" property value.
Description: This property is used in the "VRIGHT" component to
define restrictions on the components that can be written (i.e.,
by using the "CREATE" or "MOVE" commands) as well as on the values
that may take existent calendar store properties, calendar
properties, components, and properties (i.e., by using the
"MODIFY" command). Accepted values MUST match any specified
"RESTRICTION" property values.
Formal Definition: The property is defined by the following notation:
restriction = "RESTRICTION" other-params ":" cal-query CRLF
Example: The following are examples of this property:
RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'
RESTRICTION:SELECT * FROM VEVENT WHERE
SELF() IN ORGANIZER
RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN
CATEGORIES
8.33. SCOPE Property
Property Name: SCOPE
Purpose: This property identifies the objects in the CS to which the
access rights apply.
Value Type: CAL-QUERY
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in "VRIGHT" components.
Royer, et al. Experimental [Page 73]
RFC 4324 Calendar Access Protocol December 2005
Description: This property is used in the "VRIGHT" component to
define the set of objects, subject to the access right being
defined.
Formal Definition: The property is defined by the following notation:
scope = "SCOPE" other-params ":" cal-query CRLF
Example: The following is an example of this property:
SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC'
8.34. STORES-EXPANDED Property
Property Name: STORES-EXPANDED
Purpose: This property specifies if the sending endpoint expands
recurrence rules prior to storing them into the CS.
Value Type: BOOLEAN
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in a "VREPLY" component
in response to a "GET-CAPABILITY".
Note: If instead, the server detected an error in the command, it
sends a BAD completion response with a tag matching the command
(as described below) to reject the command and prevent the client
from sending any more of the command.
Melnikov & Leiba Expires January 30, 2021 [Page 7]
Internet-Draft IMAP4rev2 July 2020
It is also possible for the server to send a completion response
for some other command (if multiple commands are in progress), or
untagged data. In either case, the command continuation request
is still pending; the client takes the appropriate action for the
response, and reads another response from the server. In all
cases, the client MUST send a complete command (including
receiving all command continuation request responses and command
continuations for the command) before initiating a new command.
The protocol receiver of an IMAP4rev2 server reads a command line
from the client, parses the command and its arguments, and transmits
server data and a server command completion result response.
2.2.2. Server Protocol Sender and Client Protocol Receiver
Data transmitted by the server to the client and status responses
that do not indicate command completion are prefixed with the token
"*", and are called untagged responses.
Server data MAY be sent as a result of a client command, or MAY be
sent unilaterally by the server. There is no syntactic difference
between server data that resulted from a specific command and server
data that were sent unilaterally.
The server completion result response indicates the success or
failure of the operation. It is tagged with the same tag as the
client command which began the operation. Thus, if more than one
command is in progress, the tag in a server completion response
identifies the command to which the response applies. There are
three possible server completion responses: OK (indicating success),
NO (indicating failure), or BAD (indicating a protocol error such as
unrecognized command or command syntax error).
Servers SHOULD enforce the syntax outlined in this specification
strictly. Any client command with a protocol syntax error, including
(but not limited to) missing or extraneous spaces or arguments,
SHOULD be rejected, and the client given a BAD server completion
response.
The protocol receiver of an IMAP4rev2 client reads a response line
from the server. It then takes action on the response based upon the
first token of the response, which can be a tag, a "*", or a "+".
A client MUST be prepared to accept any server response at all times.
This includes server data that was not requested. Server data SHOULD
be recorded, so that the client can reference its recorded copy
rather than sending a command to the server to request the data. In
the case of certain server data, the data MUST be recorded.
Melnikov & Leiba Expires January 30, 2021 [Page 8]
Internet-Draft IMAP4rev2 July 2020
This topic is discussed in greater detail in the Server Responses
section.
2.3. Message Attributes
In addition to message text, each message has several attributes
associated with it. These attributes can be retrieved individually
or in conjunction with other attributes or message texts.
2.3.1. Message Numbers
Messages in IMAP4rev2 are accessed by one of two numbers; the unique
identifier or the message sequence number.
2.3.1.1. Unique Identifier (UID) Message Attribute
An unsigned non-zero 32-bit value assigned to each message, which
when used with the unique identifier validity value (see below) forms
a 64-bit value that MUST NOT refer to any other message in the
mailbox or any subsequent mailbox with the same name forever. Unique
identifiers are assigned in a strictly ascending fashion in the
mailbox; as each message is added to the mailbox it is assigned a
higher UID than the message(s) which were added previously. Unlike
message sequence numbers, unique identifiers are not necessarily
contiguous.
The unique identifier of a message MUST NOT change during the
session, and SHOULD NOT change between sessions. Any change of
unique identifiers between sessions MUST be detectable using the
UIDVALIDITY mechanism discussed below. Persistent unique identifiers
are required for a client to resynchronize its state from a previous
session with the server (e.g., disconnected or offline access clients
[IMAP-MODEL]); this is discussed further in [IMAP-DISC].
Associated with every mailbox are two 32-bit unsigned non-zero values
which aid in unique identifier handling: the next unique identifier
value (UIDNEXT) and the unique identifier validity value
(UIDVALIDITY).
The next unique identifier value is the predicted value that will be
assigned to a new message in the mailbox. Unless the unique
identifier validity also changes (see below), the next unique
identifier value MUST have the following two characteristics. First,
the next unique identifier value MUST NOT change unless new messages
are added to the mailbox; and second, the next unique identifier
value MUST change whenever new messages are added to the mailbox,
even if those new messages are subsequently expunged.
Melnikov & Leiba Expires January 30, 2021 [Page 9]
Internet-Draft IMAP4rev2 July 2020
Note: The next unique identifier value is intended to provide a
means for a client to determine whether any messages have been
delivered to the mailbox since the previous time it checked this
value. It is not intended to provide any guarantee that any
message will have this unique identifier. A client can only
assume, at the time that it obtains the next unique identifier
value, that messages arriving after that time will have a UID
greater than or equal to that value.
The unique identifier validity value is sent in a UIDVALIDITY
response code in an OK untagged response at mailbox selection time.
If unique identifiers from an earlier session fail to persist in this
session, the unique identifier validity value MUST be greater than
the one used in the earlier session. A good UIDVALIDITY value to use
is a 32-bit representation of the current date/time when the value is
assigned: this ensures that the value is unique and always increases.
Another possible alternative is a global counter that gets
incremented every time a mailbox is created.
Note: Ideally, unique identifiers SHOULD persist at all times.
Although this specification recognizes that failure to persist can
be unavoidable in certain server environments, it STRONGLY
ENCOURAGES message store implementation techniques that avoid this
problem. For example:
1. Unique identifiers MUST be strictly ascending in the mailbox
at all times. If the physical message store is re-ordered by
a non-IMAP agent, this requires that the unique identifiers in
the mailbox be regenerated, since the former unique
identifiers are no longer strictly ascending as a result of
the re-ordering.
2. If the message store has no mechanism to store unique
identifiers, it must regenerate unique identifiers at each
session, and each session must have a unique UIDVALIDITY
value.
3. If the mailbox is deleted/renamed and a new mailbox with the
same name is created at a later date, the server must either
keep track of unique identifiers from the previous instance of
the mailbox, or it must assign a new UIDVALIDITY value to the
new instance of the mailbox.
4. The combination of mailbox name, UIDVALIDITY, and UID must
refer to a single immutable (or expunged) message on that
server forever. In particular, the internal date, [RFC-5322]
size, envelope, body structure, and message texts (all
BODY[...] fetch data items) must never change. This does not
Melnikov & Leiba Expires January 30, 2021 [Page 10]
Internet-Draft IMAP4rev2 July 2020
include message numbers, nor does it include attributes that
can be set by a STORE command (e.g., FLAGS). When a message
is expunged, its UID MUST NOT be reused under the same
UIDVALIDITY value.
2.3.1.2. Message Sequence Number Message Attribute
A relative position from 1 to the number of messages in the mailbox.
This position MUST be ordered by ascending unique identifier. As
each new message is added, it is assigned a message sequence number
that is 1 higher than the number of messages in the mailbox before
that new message was added.
Message sequence numbers can be reassigned during the session. For
example, when a message is permanently removed (expunged) from the
mailbox, the message sequence number for all subsequent messages is
decremented. The number of messages in the mailbox is also
decremented. Similarly, a new message can be assigned a message
sequence number that was once held by some other message prior to an
expunge.
In addition to accessing messages by relative position in the
mailbox, message sequence numbers can be used in mathematical
calculations. For example, if an untagged "11 EXISTS" is received,
and previously an untagged "8 EXISTS" was received, three new
messages have arrived with message sequence numbers of 9, 10, and 11.
Another example, if message 287 in a 523 message mailbox has UID
12345, there are exactly 286 messages which have lesser UIDs and 236
messages which have greater UIDs.
2.3.2. Flags Message Attribute
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
removal. There are two types of flags in IMAP4rev2. A flag of
either type can be permanent or session-only.
A system flag is a flag name that is pre-defined in this
specification and begin with "\". Certain system flags (\Deleted and
\Seen) have special semantics described elsewhere in this document.
The currently-defined system flags are:
\Seen Message has been read
\Answered Message has been answered
\Flagged Message is "flagged" for urgent/special attention
Melnikov & Leiba Expires January 30, 2021 [Page 11]
Internet-Draft IMAP4rev2 July 2020
\Deleted Message is "deleted" for removal by later EXPUNGE
\Draft Message has not completed composition (marked as a draft).
\Recent This flag was in used in IMAP4rev1 and is now deprecated.
A keyword is defined by the server implementation. Keywords do not
begin with "\". Servers MAY permit the client to define new keywords
in the mailbox (see the description of the PERMANENTFLAGS response
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
SEARCH, allowed and preserved in APPEND, COPY, MOVE 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 [RFC8098] was generated
and sent for this message. See [RFC3503] for more details on how
this keyword is used.
$Junk The user (or a delivery agent on behalf of the user) may
choose to mark a message as definitely containing junk ($Junk; see
also the related keyword $NotJunk). The $Junk keyword can be used
to mark (and potentially move/delete messages later), group or
hide undesirable messages. See [IMAP-KEYWORDS-REG] for more
information.
$NotJunk The user (or a delivery agent on behalf of the user) may
choose to mark a message as definitely not containing junk
($NotJunk; see also the related keyword $Junk). The $NotJunk
keyword can be used to mark, group or show messages that the user
wants to see. See [IMAP-KEYWORDS-REG] for more information.
$Phishing The $Phishing keyword can be used by a delivery agent to
mark a message as highly likely to be a phishing email. An email
that's determined to be a phishing email by the delivery agent
should also be considered a junk email and have the appropriate
junk filtering applied, including setting the $Junk flag and
Melnikov & Leiba Expires January 30, 2021 [Page 12]
Internet-Draft IMAP4rev2 July 2020
placing in the \Junk special-use mailbox (see Section 7.2.3) if
available.
If both the $Phishing flag and the $Junk flag are set, the user
agent should display an additional warning message to the user.
User agents should not use the term "phishing" in their warning
message as most users do not understand this term. Phrasing of
the form "this message may be trying to steal your personal
information" is recommended. Additionally the user agent may
display a warning when clicking on any hyperlinks within the
message.
The requirement for both $Phishing and $Junk to be set before a
user agent displays a warning is for better backwards
compatibility with existing clients that understand the $Junk flag
but not the $Phishing flag. This so that when an unextended
client removes the $Junk flag, an extended client will also show
the correct state. See [IMAP-KEYWORDS-REG] for more information.
$Junk and $NotJunk are mutually exclusive. If more than one of them
is set for a message, the client MUST treat this as if none of them
is set and SHOULD unset both of them on the IMAP server.
Other registered keywords can be found in the "IMAP and JMAP
Keywords" registry [IMAP-KEYWORDS-REG]. New keywords SHOULD be
registered in this registry using the procedure specified in
[RFC5788].
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
message flags permanently; that is, concurrent and subsequent
sessions will see any change in permanent flags. Changes to session
flags are valid only in that session.
2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This is not
the date and time in the [RFC-5322] header, but rather a date and
time which reflects when the message was received. In the case of
messages delivered via [SMTP], this SHOULD be the date and time of
final delivery of the message as defined by [SMTP]. In the case of
messages delivered by the IMAP4rev2 COPY or MOVE command, this SHOULD
be the internal date and time of the source message. In the case of
messages delivered by the IMAP4rev2 APPEND command, this SHOULD be
the date and time as specified in the APPEND command description.
All other cases are implementation defined.
Melnikov & Leiba Expires January 30, 2021 [Page 13]
Internet-Draft IMAP4rev2 July 2020
2.3.4. [RFC-5322] Size Message Attribute
The number of octets in the message, as expressed in [RFC-5322]
format.
2.3.5. Envelope Structure Message Attribute
A parsed representation of the [RFC-5322] header of the message.
Note that the IMAP Envelope structure is not the same as an [SMTP]
envelope.
2.3.6. Body Structure Message Attribute
A parsed representation of the [MIME-IMB] body structure information
of the message.
2.4. Message Texts
In addition to being able to fetch the full [RFC-5322] text of a
message, IMAP4rev2 permits the fetching of portions of the full
message text. Specifically, it is possible to fetch the [RFC-5322]
message header, [RFC-5322] message body, a [MIME-IMB] body part, or a
[MIME-IMB] header.
3. State and Flow Diagram
Once the connection between client and server is established, an
IMAP4rev2 connection is in one of four states. The initial state is
identified in the server greeting. Most commands are only valid in
certain states. It is a protocol error for the client to attempt a
command while the connection is in an inappropriate state, and the
server will respond with a BAD or NO (depending upon server
implementation) command completion result.
3.1. Not Authenticated State
In the not authenticated state, the client MUST supply authentication
credentials before most commands will be permitted. This state is
entered when a connection starts unless the connection has been pre-
authenticated.
3.2. Authenticated State
In the authenticated state, the client is authenticated and MUST
select a mailbox to access before commands that affect messages will
be permitted. This state is entered when a pre-authenticated
connection starts, when acceptable authentication credentials have
Melnikov & Leiba Expires January 30, 2021 [Page 14]
Internet-Draft IMAP4rev2 July 2020
been provided, after an error in selecting a mailbox, or after a
successful CLOSE command.
3.3. Selected State
In a selected state, a mailbox has been selected to access. This
state is entered when a mailbox has been successfully selected.
3.4. Logout State
In the logout state, the connection is being terminated. This state
can be entered as a result of a client request (via the LOGOUT
command) or by unilateral action on the part of either the client or
server.
If the client requests the logout state, the server MUST send an
untagged BYE response and a tagged OK response to the LOGOUT command
before the server closes the connection; and the client MUST read the
tagged OK response to the LOGOUT command before the client closes the
connection.
A server SHOULD NOT unilaterally close the connection without sending
an untagged BYE response that contains the reason for having done so.
A client SHOULD NOT unilaterally close the connection, and instead
SHOULD issue a LOGOUT command. If the server detects that the client
has unilaterally closed the connection, the server MAY omit the
untagged BYE response and simply close its connection.
Melnikov & Leiba Expires January 30, 2021 [Page 15]
Internet-Draft IMAP4rev2 July 2020
+----------------------+
|connection established|
+----------------------+
||
\/
+--------------------------------------+
| server greeting |
+--------------------------------------+
|| (1) || (2) || (3)
\/ || ||
+-----------------+ || ||
|Not Authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| \/ \/ ||
|| +----------------+ ||
|| | Authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || \/ || ||
|| || +--------+ || ||
|| || |Selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
\/ \/ \/ \/
+--------------------------------------+
| Logout |
+--------------------------------------+
||
\/
+-------------------------------+
|both sides close the connection|
+-------------------------------+
(1) connection without pre-authentication (OK greeting)
(2) pre-authenticated connection (PREAUTH greeting)
(3) rejected connection (BYE greeting)
(4) successful LOGIN or AUTHENTICATE command
(5) successful SELECT or EXAMINE command
(6) CLOSE command, unsolicited CLOSED response code or
failed SELECT or EXAMINE command
(7) LOGOUT command, server shutdown, or connection closed
Melnikov & Leiba Expires January 30, 2021 [Page 16]
Internet-Draft IMAP4rev2 July 2020
4. Data Formats
IMAP4rev2 uses textual commands and responses. Data in IMAP4rev2 can
be in one of several forms: atom, number, string, parenthesized list,
or NIL. Note that a particular data item may take more than one
form; for example, a data item defined as using "astring" syntax may
be either an atom or a string.
4.1. Atom
An atom consists of one or more non-special characters.
4.1.1. Sequence set and UID set
A set of messages can be referenced by a sequence set containing
either message sequence numbers or unique identifiers. See Section 9
for details. Sequence sets can contain ranges (e.g. "5:50"), an
enumeration of specific message/UID numbers, a special symbol "*", or
a combination of the above.
A "UID set" is similar to the sequence set of unique identifiers;
however, the "*" value for a sequence number is not permitted.
4.2. Number
A number consists of one or more digit characters, and represents a
numeric value.
4.3. String
A string is in one of three forms: synchonizing literal, non-
synchronizing literal or quoted string. The synchronizing literal
form is the general form of string. The non-synchronizing literal
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.
When the distinction between synchronizing and non-synchronizing
literals is not important, this document just uses the term
"literal".
A synchronizing literal is a sequence of zero or more octets
(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
Melnikov & Leiba Expires January 30, 2021 [Page 17]
Internet-Draft IMAP4rev2 July 2020
(described later in this document) before sending the octet data (and
the remainder of the command).
The non-synchronizing literal is an alternate form of synchronizing
literal, and it may appear in communication from client to server
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 the
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
synchronizing literal MUST wait to receive a command continuation
request.
4.3.1. 8-bit and Binary Strings
8-bit textual and binary mail is supported through the use of a
[MIME-IMB] content transfer encoding. IMAP4rev2 implementations MAY
transmit 8-bit or multi-octet characters in literals, but SHOULD do
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.
Melnikov & Leiba Expires January 30, 2021 [Page 18]
Internet-Draft IMAP4rev2 July 2020
Although a BINARY content transfer encoding is defined, unencoded
binary strings are not permitted, unless returned in a <literal8> in
response to BINARY.PEEK[<section-binary>]<<partial>> or
BINARY[<section-binary>]<<partial>> FETCH data item. A "binary
string" is any string with NUL characters. A string with an
excessive amount of CTL characters MAY also be considered to be
binary. Unless returned in response to BINARY.PEEK[...]/BINARY[...]
FETCH, client and server implementations MUST encode binary data into
a textual form, such as BASE64, before transmitting the data.
4.4. Parenthesized List
Data structures are represented as a "parenthesized list"; a sequence
of data items, delimited by space, and bounded at each end by
parentheses. A parenthesized list can contain other parenthesized
lists, using multiple levels of parentheses to indicate nesting.
The empty list is represented as () -- a parenthesized list with no
members.
4.5. NIL
The special form "NIL" represents the non-existence of a particular
data item that is represented as a string or parenthesized list, as
distinct from the empty string "" or the empty parenthesized list ().
Note: NIL is never used for any data item which takes the form of
an atom. For example, a mailbox name of "NIL" is a mailbox named
NIL as opposed to a non-existent mailbox name. This is because
mailbox uses "astring" syntax which is an atom or a string.
Conversely, an addr-name of NIL is a non-existent personal name,
because addr-name uses "nstring" syntax which is NIL or a string,
but never an atom.
Melnikov & Leiba Expires January 30, 2021 [Page 19]
Internet-Draft IMAP4rev2 July 2020
Examples:
The following LIST response:
* LIST () "/" NIL
is equivalent to:
* LIST () "/" "NIL"
as LIST response ABNF is using astring for mailbox name.
However, the following response
* FETCH 1 (BODY[1] NIL)
is not equivalent to:
* FETCH 1 (BODY[1] "NIL")
The former means absence of the body part, while the latter
means that it contains literal sequence of characters "NIL".
5. Operational Considerations
The following rules are listed here to ensure that all IMAP4rev2
implementations interoperate properly.
5.1. Mailbox Naming
In IMAP4rev2, Mailbox names are encoded in Net-Unicode [NET-UNICODE]
(this differs from IMAP4rev1). Client implementations MAY attempt to
create Net-Unicode mailbox names, and MUST interpret any 8-bit
mailbox names returned by LIST as [NET-UNICODE]. Server
implementations MUST prohibit the creation of 8-bit mailbox names
that do not comply with Net-Unicode. However, servers MAY accept a
de-normalized UTF-8 mailbox name and convert it to Unicode
normalization form "NFC" (as per Net-Unicode requirements) prior to
mailbox creation. Servers that choose to accept such de-normalized
UTF-8 mailbox names MUST accept them in all IMAP commands that have a
mailbox name parameter. In particular SELECT <name> must open the
same mailbox that was successfully created with CREATE <name>, even
if <name> is a de-normalized UTF-8 mailbox name.
The case-insensitive mailbox name INBOX is a special name reserved to
mean "the primary mailbox for this user on this server". (Note that
this special name may not exist on some servers for some users, for
example if the user has no access to personal namespace.) The
interpretation of all other names is implementation-dependent.
Melnikov & Leiba Expires January 30, 2021 [Page 20]
Internet-Draft IMAP4rev2 July 2020
In particular, this specification takes no position on case
sensitivity in non-INBOX mailbox names. Some server implementations
are fully case-sensitive in ASCII range; others preserve case of a
newly-created name but otherwise are case-insensitive; and yet others
coerce names to a particular case. Client implementations must be
able to interact with any of these.
There are certain client considerations when creating a new mailbox
name:
1. Any character which is one of the atom-specials (see the Formal
Syntax) will require that the mailbox name be represented as a
quoted string or literal.
2. CTL and other non-graphic characters are difficult to represent
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
a mailbox name, it is difficult to use such mailbox names with
the LIST command due to the conflict with wildcard
interpretation.
4. Usually, a character (determined by the server implementation) is
reserved to delimit levels of hierarchy.
5. Two characters, "#" and "&", have meanings by convention, and
should be avoided except when used in that convention. See
Section 5.1.2.1 and Appendix A.1 respectively.
5.1.1. Mailbox Hierarchy Naming
If it is desired to export hierarchical mailbox names, mailbox names
MUST be left-to-right hierarchical using a single character to
separate levels of hierarchy. The same hierarchy separator character
is used for all levels of hierarchy within a single name.
5.1.2. Namespaces
Personal Namespace: A namespace that the server considers within the
personal scope of the authenticated user on a particular connection.
Typically, only the authenticated user has access to mailboxes in
their Personal Namespace. It is the part of the namespace that
belongs to the user that is allocated for mailboxes. If an INBOX
exists for a user, it MUST appear within the user's personal
namespace. In the typical case, there SHOULD be only one Personal
Namespace on a server.
Melnikov & Leiba Expires January 30, 2021 [Page 21]
Internet-Draft IMAP4rev2 July 2020
Other Users' Namespace: A namespace that consists of mailboxes from
the Personal Namespaces of other users. To access mailboxes in the
Other Users' Namespace, the currently authenticated user MUST be
explicitly granted access rights. For example, it is common for a
manager to grant to their secretary access rights to their mailbox.
In the typical case, there SHOULD be only one Other Users' Namespace
on a server.
Shared Namespace: A namespace that consists of mailboxes that are
intended to be shared amongst users and do not exist within a user's
Personal Namespace.
The namespaces a server uses MAY differ on a per-user basis.
5.1.2.1. Historic Mailbox Namespace Naming Convention
By convention, the first hierarchical element of any mailbox name
which begins with "#" identifies the "namespace" of the remainder of
the name. This makes it possible to disambiguate between different
types of mailbox stores, each of which have their own namespaces.
For example, implementations which offer access to USENET
newsgroups MAY use the "#news" namespace to partition the USENET
newsgroup namespace from that of other mailboxes. Thus, the
comp.mail.misc newsgroup would have a mailbox name of
"#news.comp.mail.misc", and the name "comp.mail.misc" can refer to
a different object (e.g., a user's private mailbox).
Namespaces that include the "#" character are not IMAP URL [IMAP-URL]
friendly requiring the "#" command.
Description: If the value is "TRUE", then the endpoint expands
recurrence rules and stores the results into the CS. If this is
"TRUE", then the "RECUR-LIMIT" property is significant because an
infinitely-recurring appointment will store no more than "RECUR-
LIMIT" property values into the CS and all other instances will be
lost.
Formal Definition: The property is specified by the following
notation:
stores-expanded = "STORES-EXPANDED" other-params ":" boolean
CRLF
The following is an example of this property:
STORES-EXPANDED:TRUE
STORES-EXPANDED:FALSE
8.35. TARGET Property
Property Name: TARGET
Royer, et al. Experimental [Page 74]
RFC 4324 Calendar Access Protocol December 2005
Purpose: This property defines the container that the issued command
will act upon. Its value is a capurl, as defined in Section 5.
Value Type: URI
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in a command component.
Description: This property value is used to specify the container
that the command will effect. When used in a command, the command
will be performed on the container that has a capurl matching the
value.
Formal Definition: The property is specified by the following
notation:
target = "TARGET" other-params ":" ( capurl / relcalid ) CRLF
Example: The following is an example of this property:
TARGET:cap://mycal.example.com
TARGET:SomeRelCalid
8.36. TRANSP Property
Property Name: TRANSP
Purpose: This property defines whether a component is transparent or
not to busy-time searches. This is a modification to [iCAL]
"TRANSP" property, in that it adds some values.
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in a component.
Description: Time Transparency is the characteristic of an object
that determines whether it appears to consume time on a calendar.
Objects that consume actual time for the individual or resource
associated with the calendar SHOULD be recorded as "OPAQUE",
allowing them to be detected by free-busy time searches. Other
objects, which do not take up the individual's (or resource's)
time SHOULD be recorded as "TRANSPARENT", making them invisible to
free/busy time searches.
Royer, et al. Experimental [Page 75]
RFC 4324 Calendar Access Protocol December 2005
Formal Definition: The property is specified by the following
notation:
transp = "TRANSP" other-params ":" transvalue CRLF
;
transvalue = "OPAQUE" ;Blocks or opaque on busy time searches.
/ "TRANSPARENT"
; Transparent on busy time searches.
/ "TRANSPARENT-NOCONFLICT"
; Transparent on busy time searches,
; and no other OPAQUE or OPAQUE-
; NOCONFLICT objects can overlap it.
;
/ "OPAQUE-NOCONFLICT"
; Opaque on busy time searches, and
; no other OPAQUE or OPAQUE-NOCONFLICT
; objects can overlap it.
;
; Default value is OPAQUE
The following is an example of this property for an object that is
opaque or blocks on free/busy time searches, and no other object
can overlap it:
TRANSP:OPAQUE-NOCONFLICT
9. New Components
9.1. VAGENDA Component
Component Name: VAGENDA
Purpose: Provide a grouping of properties that defines an agenda.
Formal Definition: There are two formats of the "VAGENDA" component.
(1) When it is being created, and (2) how it exists in the
"VCALSTORE" component.
A "VAGENDA" component in a "VCALSTORE" component is defined by the
following notes and ABNF notation:
CALSCALE - The value MUST be from the "VCALSTORE" "CALSCALE"
property list. The default is the first entry in the
VCALSTORE CALSCALE list.
CREATED - The timestamp of the calendar's create date. This
Royer, et al. Experimental [Page 76]
RFC 4324 Calendar Access Protocol December 2005
is a READ ONLY property in a "VAGENDA".
LAST-MODIFIED - The timestamp of any change to the "VAGENDA"
properties or when any component was last created, modified,
or deleted.
agenda = "BEGIN" ":" "VAGENDA" CRLF
agendaprop
*(icalobject) ; as defined in [iCAL]
"END" ":" "VAGENDA" CRLF
agendaprop = *(
; The following MUST occur exactly once.
;
allow-conflict / relcalid / calscale / created
/ default-charset / default-locale
/ default-tzid / last-mod
;
; The following MUST occur at least once.
; and the value MUST NOT be empty.
;
/ owner
;
; The following are optional,
; and MAY occur more than once.
;
/ name / related-to / other-props / x-comp
)
icalobject = ; As defined in [iCAL].
;
created = ; As defined in [iCAL].
;
related-to = ; As defined in [iCAL].
When creating a VAGENDA, use the following notation:
agendac = "BEGIN" ":" "VAGENDA" CRLF
agendacprop
*(icalobject) ; as defined in [iCAL].
"END" ":" "VAGENDA" CRLF
agendacprop = *(
; The following MUST occur exactly once.
;
allow-conflict / relcalid / calscale
/ default-charset / default-locale
/ default-tzid
Royer, et al. Experimental [Page 77]
RFC 4324 Calendar Access Protocol December 2005
;
; The following MUST occur at least once.
; and the value MUST NOT be empty.
;
/ owner
;
; The following are optional,
; and MAY occur more than once.
;
/ name / related-to / other-props / x-comp
)
To fetch all of the properties from the targeted "VAGENDA" component
but do not fetch any components, use:
SELECT * FROM VAGENDA
To fetch all of the properties from the targeted VAGENDA and all of
the contained components, use the special '*.*' value:
SELECT *.* FROM VAGENDA
9.2. VCALSTORE Component
Component Name: VCALSTORE
Purpose: Provide a grouping of properties that defines a calendar
store.
Formal Definition: A "VCALSTORE" component is defined by the
following table and ABNF notation. The creation of a "VCALSTORE"
component is an administrative task and not part of the CAP
protocol.
The following are notes to some of the properties in the
"VCALSTORE" component.
CALSCALE - A comma-separated list of CALSCALEs supported by
this CS. All "VAGENDA" component calendar CALSCALE
properties MUST be from this list. This list MUST contain
at least "GREGORIAN". The default for newly created
"VAGENDA" components is the first entry.
RELATED-TO - This is a multiple-instance property. There MUST
be a "RELATED-TO" property for each of the "VAGENDA"
components contained in the "VCALSTORE" component, each with
the "RELTYPE" parameter value set to "CHILD". Other
"RELATED-TO" properties may be included.
Royer, et al. Experimental [Page 78]
RFC 4324 Calendar Access Protocol December 2005
CREATED - The timestamp of the CS creation time. This is a
READ ONLY property.
CSID - The CSID of this calendar store. This MUST NOT be
empty. How this property is set in the VCALSTORE is an
administrative or implementation-specific issue and is not
covered in CAP. This is a READ ONLY property. A suggested
value is the fully-qualified host name or a fully-qualified
virtual host name supported by the system.
LAST-MODIFIED - The timestamp when the Properties of the
"VCALSTORE" component were last updated or calendars were
created or deleted. This is a READ ONLY PROPERTY.
calstorec = "BEGIN" ":" "VCALSTORE" CRLF
calstoreprop
*(vagendac)
"END" ":" "VCALSTORE" CRLF
;
calstoreprop = *(
; the following MUST occur exactly once
;
allow-conflict / calscale / calmaster
/ created / csid / default-charset
/ default-locale / default-vcars
/ default-tzid / last-mod / maxdate / mindate
;
; the following are optional,
; and MAY occur more than once
;
/ name / related-to / other-props / x-comp
)
;
vagendac = ; As defined in [iCAL].
;
last-mod = ; As defined in [iCAL].
To fetch all of the properties from the targeted VCALSTORE and not
fetch the calendars that it contains, use:
SELECT * FROM VCALSTORE
To fetch all of the properties from the targeted "VCALSTORE"
component and all of the contained calendars and all of those
calendars' contained properties and components, use the special '*.*'
value:
Royer, et al. Experimental [Page 79]
RFC 4324 Calendar Access Protocol December 2005
SELECT *.* FROM VCALSTORE
9.3. VCAR Component
Component Name: VCAR
Purpose: Provide a grouping of calendar access rights.
Formal Definition: A "VCAR" component is defined by the following
notation:
carc = "BEGIN" ":" "VCAR" CRLF
carprop 1*rightc
"END" ":" "VCAR" CRLF
;
carprop = 1*(
;
; 'carid' is REQUIRED,
; but MUST NOT occur more than once
;
carid /
;
; the following are OPTIONAL,
; and MAY occur more than once
;
name / decreed / other-props
)
Description: A "VCAR" component is a grouping of properties, and
"VRIGHT" components, that represents access rights granted or
denied to UPNs.
The "CARID" property specifies the local identifier for the "VCAR"
component. The "NAME" property specifies a localizable display
name.
Example: In the following example, the UPN "foo@example.com" is given
search access to the "DTSTART" and "DTEND" VEVENT properties. No
other access is specified:
Royer, et al. Experimental [Page 80]
RFC 4324 Calendar Access Protocol December 2005
BEGIN:VCAR
CARID:View Start and End Times
NAME:View Start and End Times
BEGIN:VRIGHT
GRANT:foo@example.com
PERMISSION:SEARCH
SCOPE:SELECT DTSTART,DTEND FROM VEVENT
END:VRIGHT
END:VCAR
In this example, all UPNs are given search access to "DTSTART" and
"DTEND" properties of VEVENT components. "All CUs and UGs" are
specified by the UPN value "*". Note that this enumerated UPN
value is not in quotes:
BEGIN:VCAR
CARID:ViewStartEnd2
NAME:View Start and End Times 2
BEGIN:VRIGHT
GRANT:*
PERMISSION:SEARCH
SCOPE:SELECT DTSTART,DTEND FROM VEVENT
END:VRIGHT
END:VCAR
In these examples, full calendar access rights are given to the
CAL-OWNERS(), and a hypothetical administrator is given access
rights to specify calendar access rights. If no other rights are
specified, only these two UPNs can specify calendar access rights:
BEGIN:VCAR
CARID:some-id-3
NAME:Only OWNER or ADMIN Settable VCARs
BEGIN:VRIGHT
GRANT:CAL-OWNERS()
PERMISSION:*
SCOPE:SELECT * FROM VAGENDA
END:VRIGHT
BEGIN:VRIGHT
GRANT:cal-admin@example.com
PERMISSION:*
SCOPE:SELECT * FROM VCAR
RESTRICTION:SELECT * FROM VCAR
END:VRIGHT
END:VCAR
In this example, rights to write, search, modify or delete
calendar access are denied to all UPNs. This example would
Royer, et al. Experimental [Page 81]
RFC 4324 Calendar Access Protocol December 2005
disable providing different access rights to the calendar store or
calendar. This calendar access right should be specified with
great care, as it removes the ability to change calendar access;
even for the owner or administrator. It could be used by small
devices that do not support changing any VCAR:
BEGIN:VCAR
CARID:VeryRestrictiveVCAR-2
NAME:No CAR At All
BEGIN:VRIGHT
DENY:*
PERMISSION:*
SCOPE:SELECT * FROM VCAR
END:VRIGHT
END:VCAR
9.4. VRIGHT Component
Component Name: "VRIGHT"
Purpose: Provide a grouping of properties that describe an access
right (granted or denied).
Formal Definition: A "VRIGHT" component is defined by the following
notation:
rightc = "BEGIN" ":" "VRIGHT" CRLF
rightprop
"END" ":" "VRIGHT" CRLF
;
rightprop = 2*(
;
; either 'grant' or 'deny' MUST
; occur at least once
; and MAY occur more than once
;
grant / deny /
;
; 'permission' MUST occur at least once
; and MAY occur more than once
;
permission /
;
; the following are optional,
; and MAY occur more than once
;
scope / restriction / other-props
)
Royer, et al. Experimental [Page 82]
RFC 4324 Calendar Access Protocol December 2005quot; character to be represented as %23 when
within URLs. As such, server implementers MAY instead consider using
namespace prefixes that do not contain the "#" character.
5.1.2.2. Common namespace models
Previous version of this protocol does not define a default server
namespace. Two common namespace models have evolved:
The "Personal Mailbox" model, in which the default namespace that is
presented consists of only the user's personal mailboxes. To access
shared mailboxes, the user must use an escape mechanism to reach
another namespace.
The "Complete Hierarchy" model, in which the default namespace that
is presented includes the user's personal mailboxes along with any
other mailboxes they have access to.
Melnikov & Leiba Expires January 30, 2021 [Page 22]
Internet-Draft IMAP4rev2 July 2020
5.2. Mailbox Size and Message Status Updates
At any time, a server can send data that the client did not request.
Sometimes, such behavior is REQUIRED. For example, agents other than
the server MAY add messages to the mailbox (e.g., new message
delivery), change the flags of the messages in the mailbox (e.g.,
simultaneous access to the same mailbox by multiple agents), or even
remove messages from the mailbox. A server MUST send mailbox size
updates automatically if a mailbox size change is observed during the
processing of a command. A server SHOULD send message flag updates
automatically, without requiring the client to request such updates
explicitly.
Special rules exist for server notification of a client about the
removal of messages to prevent synchronization errors; see the
description of the EXPUNGE response for more detail. In particular,
it is NOT permitted to send an EXISTS response that would reduce the
number of messages in the mailbox; only the EXPUNGE response can do
this.
Regardless of what implementation decisions a client makes on
remembering data from the server, a client implementation MUST record
mailbox size updates. It MUST NOT assume that any command after the
initial mailbox selection will return the size of the mailbox.
5.3. Response when no Command in Progress
Server implementations are permitted to send an untagged response
(except for EXPUNGE) while there is no command in progress. Server
implementations that send such responses MUST deal with flow control
considerations. Specifically, they MUST either (1) verify that the
size of the data does not exceed the underlying transport's available
window size, or (2) use non-blocking writes.
5.4. Autologout Timer
If a server has an inactivity autologout timer that applies to
sessions after authentication, the duration of that timer MUST be at
least 30 minutes. The receipt of ANY command from the client during
that interval SHOULD suffice to reset the autologout timer.
5.5. Multiple Commands in Progress (Command Pipelining)
The client MAY send another command without waiting for the
completion result response of a command, subject to ambiguity rules
(see below) and flow control constraints on the underlying data
stream. Similarly, a server MAY begin processing another command
before processing the current command to completion, subject to
Melnikov & Leiba Expires January 30, 2021 [Page 23]
Internet-Draft IMAP4rev2 July 2020
ambiguity rules. However, any command continuation request responses
and command continuations MUST be negotiated before any subsequent
command is initiated.
The exception is if an ambiguity would result because of a command
that would affect the results of other commands. If the server
detects a possible ambiguity, it MUST execute commands to completion
in the order given by the client.
The most obvious example of ambiguity is when a command would affect
the results of another command, e.g., a FETCH of a message's flags
and a STORE of that same message's flags.
A non-obvious ambiguity occurs with commands that permit an untagged
EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
since an untagged EXPUNGE response can invalidate sequence numbers in
a subsequent command. This is not a problem for FETCH, STORE, or
SEARCH commands because servers are prohibited from sending EXPUNGE
responses while any of those commands are in progress. Therefore, if
the client sends any command other than FETCH, STORE, or SEARCH, it
MUST wait for the completion result response before sending a command
with message sequence numbers.
Note: EXPUNGE responses are permitted while UID FETCH, UID STORE,
and UID SEARCH are in progress. If the client sends a UID
command, it MUST wait for a completion result response before
sending a command which uses message sequence numbers (this may
include UID SEARCH). Any message sequence numbers in an argument
to UID SEARCH are associated with messages prior to the effect of
any untagged EXPUNGE returned by the UID SEARCH.
For example, the following non-waiting command sequences are invalid:
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
The following are examples of valid non-waiting command sequences:
FETCH + STORE + SEARCH + NOOP
STORE + COPY + EXPUNGE
UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
command sequence, depending upon whether or not the second UID
SEARCH contains message sequence numbers.
Melnikov & Leiba Expires January 30, 2021 [Page 24]
Internet-Draft IMAP4rev2 July 2020
Use of SEARCH result variable (see Section 6.4.4.1) creates direct
dependency between two commands. See Section 6.4.4.2 for more
considerations about pipelining such dependent commands.
6. Client Commands
IMAP4rev2 commands are described in this section. Commands are
organized by the state in which the command is permitted. Commands
which are permitted in multiple states are listed in the minimum
permitted state (for example, commands valid in authenticated and
selected state are listed in the authenticated state commands).
Command arguments, identified by "Arguments:" in the command
descriptions below, are described by function, not by syntax. The
precise syntax of command arguments is described in the Formal Syntax
(Section 9).
Some commands cause specific server responses to be returned; these
are identified by "Responses:" in the command descriptions below.
See the response descriptions in the Responses section for
information on these responses, and the Formal Syntax section for the
precise syntax of these responses. It is possible for server data to
be transmitted as a result of any command. Thus, commands that do
not specifically require server data specify "no specific responses
for this command" instead of "none".
The "Result:" in the command description refers to the possible
tagged status responses to a command, and any special interpretation
of these status responses.
The state of a connection is only changed by successful commands
which are documented as changing state. A rejected command (BAD
response) never changes the state of the connection or of the
selected mailbox. A failed command (NO response) generally does not
change the state of the connection or of the selected mailbox; the
exception being the SELECT and EXAMINE commands.
6.1. Client Commands - Any State
The following commands are valid in any state: CAPABILITY, NOOP, and
LOGOUT.
6.1.1. CAPABILITY Command
Arguments: none
Responses: REQUIRED untagged response: CAPABILITY
Melnikov & Leiba Expires January 30, 2021 [Page 25]
Internet-Draft IMAP4rev2 July 2020
Result: OK - capability completed
BAD - command unknown or arguments invalid
The CAPABILITY command requests a listing of capabilities that the
server supports. The server MUST send a single untagged CAPABILITY
response with "IMAP4rev2" as one of the listed capabilities before
the (tagged) OK response.
A capability name which begins with "AUTH=" indicates that the server
supports that particular authentication mechanism. All such names
are, by definition, part of this specification. For example, the
authorization capability for an experimental "blurdybloop"
authenticator would be "AUTH=XBLURDYBLOOP" and not
"XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
Other capability names refer to extensions, revisions, or amendments
to this specification. See the documentation of the CAPABILITY
response for additional information. No capabilities, beyond the
base IMAP4rev2 set defined in this specification, are enabled without
explicit client action to invoke the capability.
Client and server implementations MUST implement the STARTTLS,
LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN]) capabilities.
See the Security Considerations section for important information.
See the section entitled "Client Commands - Experimental/Expansion"
for information about the form of site or implementation-specific
capabilities.
Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed
6.1.2. NOOP Command
Arguments: none
Responses: no specific responses for this command (but see below)
Result: OK - noop completed
BAD - command unknown or arguments invalid
Melnikov & Leiba Expires January 30, 2021 [Page 26]
Internet-Draft IMAP4rev2 July 2020
The NOOP command always succeeds. It does nothing.
Since any command can return a status update as untagged data, the
NOOP command can be used as a periodic poll for new messages or
message status updates during a period of inactivity (the IDLE
command Section 6.3.13 should be used instead of NOOP if real-time
updates to mailbox state are desirable). The NOOP command can also
be used to reset any inactivity autologout timer on the server.
Example: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
6.1.3. LOGOUT Command
Arguments: none
Responses: REQUIRED untagged response: BYE
Result: OK - logout completed
BAD - command unknown or arguments invalid
The LOGOUT command informs the server that the client is done with
the connection. The server MUST send a BYE untagged response before
the (tagged) OK response, and then close the network connection.
Example: C: A023 LOGOUT
S: * BYE IMAP4rev2 Server logging out
S: A023 OK LOGOUT completed
(Server and client then close the connection)
6.2. Client Commands - Not Authenticated State
In the not authenticated state, the AUTHENTICATE or LOGIN command
establishes authentication and enters the authenticated state. The
AUTHENTICATE command provides a general mechanism for a variety of
authentication techniques, privacy protection, and integrity
checking; whereas the LOGIN command uses a traditional user name and
plaintext password pair and has no means of establishing privacy
protection or integrity checking.
Melnikov & Leiba Expires January 30, 2021 [Page 27]
Internet-Draft IMAP4rev2 July 2020
The STARTTLS command is an alternate form of establishing session
privacy protection and integrity checking, but does not by itself
establish authentication or enter the authenticated state.
Server implementations MAY allow access to certain mailboxes without
establishing authentication. This can be done by means of the
ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older
convention is a LOGIN command using the userid "anonymous"; in this
case, a password is required although the server may choose to accept
any password. The restrictions placed on anonymous users are
implementation-dependent.
Once authenticated (including as anonymous), it is not possible to
re-enter not authenticated state.
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
the following commands are valid in the not authenticated state:
STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
section for important information about these commands.
6.2.1. STARTTLS Command
Arguments: none
Responses: no specific response for this command
Result: OK - starttls completed, begin TLS negotiation
BAD - command unknown or arguments invalid
A [TLS] negotiation begins immediately after the CRLF at the end of
the tagged OK response from the server. Once a client issues a
STARTTLS command, it MUST NOT issue further commands until a server
response is seen and the [TLS] negotiation is complete.
The server remains in the non-authenticated state, even if client
credentials are supplied during the [TLS] negotiation. This does not
preclude an authentication mechanism such as EXTERNAL (defined in
[SASL]) from using client identity determined by the [TLS]
negotiation.
Once [TLS] has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against man-in-
the-middle attacks which alter the capabilities list prior to
STARTTLS. The server MAY advertise different capabilities, and in
particular SHOULD NOT advertise the STARTTLS capability, after a
successful STARTTLS command.
Melnikov & Leiba Expires January 30, 2021 [Page 28]
Internet-Draft IMAP4rev2 July 2020
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
6.2.2. AUTHENTICATE Command
Arguments: SASL authentication mechanism name
OPTIONAL initial response
Responses: continuation data can be requested
Result: OK - authenticate completed, now in authenticated state
NO - authenticate failure: unsupported authentication
mechanism, credentials rejected
BAD - command unknown or arguments invalid,
authentication exchange cancelled
The AUTHENTICATE command indicates a [SASL] authentication mechanism
to the server. If the server supports the requested authentication
mechanism, it performs an authentication protocol exchange to
authenticate and identify the client. It MAY also negotiate an
OPTIONAL security layer for subsequent protocol interactions. If the
requested authentication mechanism is not supported, the server
SHOULD reject the AUTHENTICATE command by sending a tagged NO
response.
The AUTHENTICATE command supports the optional "initial response"
feature defined in Section 5.1 of [SASL]. The client doesn't need to
use it. If a SASL mechanism supports "initial response", but it is
not specified by the client, the server handles this as specified in
Section 3 of [SASL].
The service name specified by this protocol's profile of [SASL] is
"imap".
The authentication protocol exchange consists of a series of server
challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a command
continuation request response with the "+" token followed by a BASE64
encoded (see Section 4 of [RFC4648]) string. The client response
Melnikov & Leiba Expires January 30, 2021 [Page 29]
Internet-Draft IMAP4rev2 July 2020
consists of a single line consisting of a BASE64 encoded string. If
the client wishes to cancel an authentication exchange, it issues a
line consisting of a single "*". If the server receives such a
response, or if it receives an invalid BASE64 string (e.g.
characters outside the BASE64 alphabet, or non-terminal "="), it MUST
reject the AUTHENTICATE command by sending a tagged BAD response.
As with any other client response, this initial response MUST be
encoded as BASE64. It also MUST be transmitted outside of a quoted
string or literal. To send a zero-length initial response, the
client MUST send a single pad character ("="). This indicates that
the response is present, but is a zero-length string.
When decoding the BASE64 data in the initial response, decoding
errors MUST be treated as in any normal SASL client response, i.e.
with a tagged BAD response. In particular, the server should check
for any characters not explicitly allowed by the BASE64 alphabet, as
well as any sequence of BASE64 characters that contains the pad
character ('=') anywhere other than the end of the string (e.g.,
"=AAA" and "AAA=BBB" are not allowed).
If the client uses an initial response with a SASL mechanism that
does not support an initial response, the server MUST reject the
command with a tagged BAD response.
If a security layer is negotiated through the [SASL] authentication
exchange, it takes effect immediately following the CRLF that
concludes the authentication exchange for the client, and the CRLF of
the tagged OK response for the server.
While client and server implementations MUST implement the
AUTHENTICATE command itself, it is not required to implement any
authentication mechanisms other than the PLAIN mechanism described in
[PLAIN]. Also, an authentication mechanism is not required to
support any security layers.
Note: a server implementation MUST implement a configuration in
which it does NOT permit any plaintext password mechanisms, unless
either the STARTTLS command has been negotiated or some other
mechanism that protects the session from password snooping has
been provided. Server sites SHOULD NOT use any configuration
which permits a plaintext password mechanism without such a
protection mechanism against password snooping. Client and server
implementations SHOULD implement additional [SASL] mechanisms that
do not use plaintext passwords, such the GSSAPI mechanism
described in [SASL] and/or the SCRAM-SHA-256/SCRAM-SHA-256-PLUS
[SCRAM-SHA-256] mechanisms.
Melnikov & Leiba Expires January 30, 2021 [Page 30]
Internet-Draft IMAP4rev2 July 2020
Servers and clients can support multiple authentication mechanisms.
The server SHOULD list its supported authentication mechanisms in the
response to the CAPABILITY command so that the client knows which
authentication mechanisms to use.
A server MAY include a CAPABILITY response code in the tagged OK
response of a successful AUTHENTICATE command in order to send
capabilities automatically. It is unnecessary for a client to send a
separate CAPABILITY command if it recognizes these automatic
capabilities. This should only be done if a security layer was not
negotiated by the AUTHENTICATE command, because the tagged OK
response as part of an AUTHENTICATE command is not protected by
encryption/integrity checking. [SASL] requires the client to re-
issue a CAPABILITY command in this case. The server MAY advertise
different capabilities after a successful AUTHENTICATE command.
If an AUTHENTICATE command fails with a NO response, the client MAY
try another authentication mechanism by issuing another AUTHENTICATE
command. It MAY also attempt to authenticate by using the LOGIN
command (see Section 6.2.3 for more detail). In other words, the
client MAY request authentication types in decreasing order of
preference, with the LOGIN command as a last resort.
The authorization identity passed from the client to the server
during the authentication exchange is interpreted by the server as
the user name whose privileges the client is requesting.
Melnikov & Leiba Expires January 30, 2021 [Page 31]
Internet-Draft IMAP4rev2 July 2020
Example: S: * OK IMAP4rev2 Server
C: A001 AUTHENTICATE GSSAPI
S: +
C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
C:
S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
ceP2CWY0SR0fAQAgAAQEBAQ=
C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
wkhbfa2QteAQAgAG1yYwE=
S: A001 OK GSSAPI authentication successful
Note: The line breaks within server challenges and client responses
are for editorial clarity and are not in real authenticators.
6.2.3. LOGIN Command
Arguments: user name
password
Responses: no specific responses for this command
Result: OK - login completed, now in authenticated state
NO - login failure: user name or password rejected
BAD - command unknown or arguments invalid
The LOGIN command identifies the client to the server and carries the
plaintext password authenticating this user.
A server MAY include a CAPABILITY response code in the tagged OK
response to a successful LOGIN command in order to send capabilities
automatically. It is unnecessary for a client to send a separate
CAPABILITY command if it recognizes these automatic capabilities.
Melnikov & Leiba Expires January 30, 2021 [Page 32]
Internet-Draft IMAP4rev2 July 2020
Example: C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed
Note: Use of the LOGIN command over an insecure network (such as the
Internet) is a security risk, because anyone monitoring network
traffic can obtain plaintext passwords. The LOGIN command SHOULD NOT
be used except as a last resort, and it is recommended that client
implementations have a means to disable any automatic use of the
LOGIN command.
Unless either the client is accessing IMAP service on IMAPS port
[RFC8314], the STARTTLS command has been negotiated or some other
mechanism that protects the session from password snooping has been
provided, a server implementation MUST implement a configuration in
which it advertises the LOGINDISABLED capability and does NOT permit
the LOGIN command. Server sites SHOULD NOT use any configuration
which permits the LOGIN command without such a protection mechanism
against password snooping. A client implementation MUST NOT send a
LOGIN command if the LOGINDISABLED capability is advertised.
6.3. Client Commands - Authenticated State
In the authenticated state, commands that manipulate mailboxes as
atomic entities are permitted. Of these commands, the SELECT and
EXAMINE commands will select a mailbox for access and enter the
selected state.
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
the following commands are valid in the authenticated state: ENABLE,
SELECT, EXAMINE, NAMESPACE, CREATE, DELETE, RENAME, SUBSCRIBE,
UNSUBSCRIBE, LIST, STATUS, APPEND and IDLE.
6.3.1. ENABLE Command
Arguments: capability names
Responses: no specific responses for this command
Result: OK - Relevant capabilities enabled
BAD - No arguments, or syntax error in an argument
Several IMAP extensions allow the server to return unsolicited
responses specific to these extensions in certain circumstances.
However, servers cannot send those unsolicited responses (with the
exception of response codes (see Section 7.1) included in tagged or
untagged OK/NO/BAD responses, which can always be sent) until they
know that the clients support such extensions and thus won't choke on
the extension response data.
Melnikov & Leiba Expires January 30, 2021 [Page 33]
Internet-Draft IMAP4rev2 July 2020
The ENABLE command provides an explicit indication from the client
that it supports particular extensions. It is designed such that the
client can send a simple constant string with the extensions it
supports, and the server will enable the shared subset that both
support.
The ENABLE command takes a list of capability names, and requests the
server to enable the named extensions. Once enabled using ENABLE,
each extension remains active until the IMAP connection is closed.
For each argument, the server does the following:
o If the argument is not an extension known to the server, the
server MUST ignore the argument.
o If the argument is an extension known to the server, and it is not
specifically permitted to be enabled using ENABLE, the server MUST
ignore the argument. (Note that knowing about an extension
doesn't necessarily imply supporting that extension.)
o If the argument is an extension that is supported by the server
and that needs to be enabled, the server MUST enable the extension
for the duration of the connection. Note that once an extension
is enabled, there is no way to disable it.
If the ENABLE command is successful, the server MUST send an untagged
ENABLED response Section 7.2.1.
Clients SHOULD only include extensions that need to be enabled by the
server. For example, a client can enable IMAP4rev2 specific
behaviour when both IMAP4rev1 and IMAP4rev2 are advertised in the
CAPABILITY response. Future RFCs may add to this list.
The ENABLE command is only valid in the authenticated state, before
any mailbox is selected. Clients MUST NOT issue ENABLE once they
SELECT/EXAMINE a mailbox; however, server implementations don't have
to check that no mailbox is selected or was previously selected
during the duration of a connection.
The ENABLE command can be issued multiple times in a session. It is
additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
single command "ENABLE a b c". When multiple ENABLE commands are
issued, each corresponding ENABLED response SHOULD only contain
extensions enabled by the corresponding ENABLE command, i.e. for the
above example, the ENABLED response to "ENABLE c" should not contain
"a" or "b".
Melnikov & Leiba Expires January 30, 2021 [Page 34]
Internet-Draft IMAP4rev2 July 2020
There are no limitations on pipelining ENABLE. For example, it is
possible to send ENABLE and then immediately SELECT, or a LOGIN
immediately followed by ENABLE.
The server MUST NOT change the CAPABILITY list as a result of
executing ENABLE; i.e., a CAPABILITY command issued right after an
ENABLE command MUST list the same capabilities as a CAPABILITY
command issued before the ENABLE command. This is demonstrated in
the following example:
C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t3 OK foo again
In the following example, the client enables CONDSTORE:
C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled
6.3.1.1. Note to Designers of Extensions That May Use the ENABLE
Command
Designers of IMAP extensions are discouraged from creating extensions
that require ENABLE unless there is no good alternative design.
Specifically, extensions that cause potentially incompatible behavior
changes to deployed server responses (and thus benefit from ENABLE)
have a higher complexity cost than extensions that do not.
6.3.2. SELECT Command
Arguments: mailbox name
Responses: REQUIRED untagged responses: FLAGS, EXISTS
REQUIRED OK untagged responses: PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY
OPTIONAL untagged response: LIST
Result: OK - select completed, now in selected state
NO - select failure, now in authenticated state: no
such mailbox, can't access mailbox
BAD - command unknown or arguments invalid
Melnikov & Leiba Expires January 30, 2021 [Page 35]
Internet-Draft IMAP4rev2 July 2020
The SELECT command selects a mailbox so that messages in the mailbox
can be accessed. Before returning an OK to the client, the server
MUST send the following untagged data to the client. (The order of
individual responses is not important.) Note that earlier versions
of this protocol only required the FLAGS and EXISTS untagged data;
consequently, client implementations SHOULD implement default
behavior for missing data as discussed with the individual item.
FLAGS Defined flags in the mailbox. See the description of the
FLAGS response for more detail.
<n> EXISTS The number of messages in the mailbox. See the
description of the EXISTS response for more detail.
LIST If the server allows de-normalized UTF-8 mailbox names (see
Section 5.1) and the supplied mailbox name differs from the
normalized version, the server SHOULD return LIST with OLDNAME
extended data item. See Section 6.3.9.7 for more details.
OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that
the client can change permanently. If this is missing, the client
should assume that all flags can be changed permanently.
OK [UIDNEXT <n>] The next unique identifier value. Refer to
Section 2.3.1.1 for more information. If this is missing, the
client can not make any assumptions about the next unique
identifier value.
OK [UIDVALIDITY <n>] The unique identifier validity value. Refer to
Section 2.3.1.1 for more information. If this is missing, the
server does not support unique identifiers.
Only one mailbox can be selected at a time in a connection;
simultaneous access to multiple mailboxes requires multiple
connections. The SELECT command automatically deselects any
currently selected mailbox before attempting the new selection.
Consequently, if a mailbox is selected and a SELECT command that
fails is attempted, no mailbox is selected. When deselecting a
selected mailbox, the server MUST return an untagged OK response with
the "[CLOSED]" response code when the currently selected mailbox is
closed (see Paragraph 10).
If the client is permitted to modify the mailbox, the server SHOULD
prefix the text of the tagged OK response with the "[READ-WRITE]"
response code.
If the client is not permitted to modify the mailbox but is permitted
read access, the mailbox is selected as read-only, and the server
Melnikov & Leiba Expires January 30, 2021 [Page 36]
Internet-Draft IMAP4rev2 July 2020
MUST prefix the text of the tagged OK response to SELECT with the
"[READ-ONLY]" response code. Read-only access through SELECT differs
from the EXAMINE command in that certain read-only mailboxes MAY
permit the change of permanent state on a per-user (as opposed to
global) basis. Netnews messages marked in a server-based .newsrc
file are an example of such per-user permanent state that can be
modified with read-only mailboxes.
Example: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
Example: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
[...some time later...]
C: A143 SELECT Drafts
S: * OK [CLOSED] Previous mailbox is now closed
S: * 5 EXISTS
S: * OK [UIDVALIDITY 9877410381] UIDs valid
S: * OK [UIDNEXT 102] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \Answered
\Flagged \Draft \*)] System flags and keywords allowed
S: A143 OK [READ-WRITE] SELECT completed
Note that IMAP4rev1 compliant servers can also send the untagged
RECENT response which was deprecated in IMAP4rev2. E.g. "* 0
RECENT". Pure IMAP4rev2 clients are advised to ignore the untagged
RECENT response.
6.3.3. EXAMINE Command
Arguments: mailbox name
Responses: REQUIRED untagged responses: FLAGS, EXISTS
REQUIRED OK untagged responses: PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY
OPTIONAL untagged response: LIST
Melnikov & Leiba Expires January 30, 2021 [Page 37]
Internet-Draft IMAP4rev2 July 2020
Result: OK - examine completed, now in selected state
NO - examine failure, now in authenticated state: no
such mailbox, can't access mailbox BAD - command unknown
or arguments invalid
The EXAMINE command is identical to SELECT and returns the same
output; however, the selected mailbox is identified as read-only. No
changes to the permanent state of the mailbox, including per-user
state, are permitted.
The text of the tagged OK response to the EXAMINE command MUST begin
with the "[READ-ONLY]" response code.
Example: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
6.3.4. CREATE Command
Arguments: mailbox name
Responses: OPTIONAL untagged response: LIST
Result: OK - create completed
NO - create failure: can't create mailbox with that name
BAD - command unknown or arguments invalid
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
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
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 server decides to convert (normalize)
the name, it SHOULD return an untagged LIST with OLDNAME extended
data item, with the OLDNAME value being the supplied mailbox name and
the name parameter being the normalized mailbox name. (See
Section 6.3.9.7 for more details.)
Mailboxes created in one IMAP session MAY be announced to other IMAP
sessions using unsolicited LIST response. If the server
automatically subscribes a mailbox when it is created, then the
Melnikov & Leiba Expires January 30, 2021 [Page 38]
Internet-Draft IMAP4rev2 July 2020
unsolicited LIST response for each affected subscribed mailbox name
MUST include the \Subscribed attribute.
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
declaration that the client intends to create mailbox names under
this name in the hierarchy. Server implementations that do not
require this declaration MUST ignore the declaration. In any case,
the name created is without the trailing hierarchy delimiter.
If the server's hierarchy separator character appears elsewhere in
the name, the server SHOULD create any superior hierarchical names
that are needed for the CREATE command to be successfully completed.
In other words, an attempt to create "foo/bar/zap" on a server in
which "/" is the hierarchy separator character SHOULD create foo/ and
foo/bar/ if they do not already exist.
If a new mailbox is created with the same name as a mailbox which was
deleted, its unique identifiers MUST be greater than any unique
identifiers used in the previous incarnation of the mailbox UNLESS
the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail.
Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
C: A005 CREATE NonNormalized
S: * LIST () "/" "Normalized" ("OLDNAME" ("NonNormalized"))
S: A005 OK CREATE completed
(in the last example imagine that "NonNormalized" is
a non NFC normalized Unicode mailbox name and that
"Normalized" is its NFC normalized version.)
Note: The interpretation of this example depends on whether "/"
was returned as the hierarchy separator from LIST. If "/" is the
hierarchy separator, a new level of hierarchy named "owatagusiam"
with a member called "blurdybloop" is created. Otherwise, two
mailboxes at the same hierarchy level are created.
6.3.5. DELETE Command
Arguments: mailbox name
Responses: OPTIONAL untagged response: LIST
Result: OK - delete completed
Melnikov & Leiba Expires January 30, 2021 [Page 39]
Internet-Draft IMAP4rev2 July 2020
NO - delete failure: can't delete mailbox with that name
BAD - command unknown or arguments invalid
The DELETE command permanently removes the mailbox with the given
name. A tagged OK response is returned only if the mailbox has been
deleted. It is an error to attempt to delete INBOX or a mailbox name
that does not exist.
The DELETE command MUST NOT remove inferior hierarchical names. For
example, if a mailbox "foo" has an inferior "foo.bar" (assuming "."
is the hierarchy delimiter character), removing "foo" MUST NOT remove
"foo.bar". It is an error to attempt to delete a name that has
inferior hierarchical names and also has the \Noselect mailbox name
attribute (see the description of the LIST response for more
details).
It is permitted to delete a name that has inferior hierarchical names
and does not have the \Noselect mailbox name attribute. If the
server implementation does not permit deleting the name while
inferior hierarchical names exists then it SHOULD disallow the DELETE
command by returning a tagged NO response. The NO response SHOULD
include the HASCHILDREN response code. Alternatively the server MAY
allow the DELETE command, but sets the \Noselect mailbox name
attribute for that name.
If the server returns OK response, all messages in that mailbox are
removed by the DELETE command.
The value of the highest-used unique identifier of the deleted
mailbox MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation, UNLESS
the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail.
Mailboxes deleted in one IMAP session MAY be announced to other IMAP
sessions using unsolicited LIST response, containing the
"\NonExistent" attribute.
Melnikov & Leiba Expires January 30, 2021 [Page 40]
Internet-Draft IMAP4rev2 July 2020
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 DELETE blurdybloop
S: A683 OK DELETE completed
C: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names
C: A685 DELETE foo/bar
S: A685 OK DELETE Completed
C: A686 LIST "" *
S: * LIST (\Noselect) "/" foo
S: A686 OK LIST completed
C: A687 DELETE foo
S: A687 OK DELETE Completed
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
6.3.6. RENAME Command
Arguments: existing mailbox name
new mailbox name
Responses: OPTIONAL untagged response: LIST
Result: OK - rename completed
NO - rename failure: can't rename mailbox with that name,
can't rename to mailbox with that name
BAD - command unknown or arguments invalid
The RENAME command changes the name of a mailbox. A tagged OK
response is returned only if the mailbox has been renamed. It is an
error to attempt to rename from a mailbox name that does not exist or
Melnikov & Leiba Expires January 30, 2021 [Page 41]
Internet-Draft IMAP4rev2 July 2020
to a mailbox name that already exists. Any error in renaming will
return a tagged NO response.
If the name has inferior hierarchical names, then the inferior
hierarchical names MUST also be renamed. For example, a rename of
"foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy
delimiter character) to "zap/bar".
If the server's hierarchy separator character appears in the name,
the server SHOULD create any superior hierarchical names that are
needed for the RENAME command to complete successfully. In other
words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
server in which "/" is the hierarchy separator character in the
corresponding namespace SHOULD create baz/ and baz/rag/ if they do
not already exist.
The value of the highest-used unique identifier of the old mailbox
name MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation, UNLESS
the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail.
Renaming INBOX is permitted, and has special behavior. (Note that
some servers disallow renaming INBOX, so clients need to be able to
handle such RENAME failing). It moves all messages in INBOX to a new
mailbox with the given name, leaving INBOX empty. If the server
implementation supports inferior hierarchical names of INBOX, these
are unaffected by a rename of INBOX.
If the server allows creation of mailboxes with names that are not
valid Net-Unicode names, the server normalizes both the existing
mailbox name parameter and the new mailbox name parameter. If the
normalized version of any of these 2 parameters differs from the
corresponding supplied version, the server SHOULD return an untagged
LIST response with OLDNAME extended data item, with the OLDNAME value
being the supplied existing mailbox name and the name parameter being
the normalized new mailbox name (see Section 6.3.9.7). This would
allow the client to correlate supplied name with the normalized name.
Mailboxes renamed in one IMAP session MAY be announced to other IMAP
sessions using unsolicited LIST response with OLDNAME extended data
item.
In both of the above cases: if the server automatically subscribes a
mailbox when it is renamed, then the unsolicited LIST response for
each affected subscribed mailbox name MUST include the \Subscribed
attribute. No unsolicited LIST responses need to be sent for
children mailboxes, if any. When INBOX is successfully renamed, a
Melnikov & Leiba Expires January 30, 2021 [Page 42]
Internet-Draft IMAP4rev2 July 2020
new INBOX is assumed to be created. No unsolicited LIST responses
need to be sent for INBOX in this case.
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed
C: A684 RENAME foo zowie
S: A684 OK RENAME Completed
C: A685 LIST "" *
S: * LIST () "/" sarasoop
S: * LIST (\Noselect) "/" zowie
S: * LIST () "/" zowie/bar
S: A685 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
Note that renaming a mailbox doesn't update subscription information
on the original name. To keep subscription information in sync, the
following sequence of commands can be used:
C: 1001 RENAME X Y
C: 1002 SUBSCRIBE Y
C: 1003 UNSUBSCRIBE X
Note that the above sequence of commands doesn't account for updating
subscription for any children mailboxes of mailbox X.
6.3.7. SUBSCRIBE Command
Arguments: mailbox
Responses: no specific responses for this command
Result: OK - subscribe completed
Melnikov & Leiba Expires January 30, 2021 [Page 43]
Internet-Draft IMAP4rev2 July 2020
NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid
The SUBSCRIBE command adds the specified mailbox name to the server's
set of "active" or "subscribed&
Description: A "VRIGHT" component is a grouping of calendar access
right properties.
The "GRANT" property specifies the UPN that is being granted
access. The "DENY" property specifies the UPN that is being
denied access. The "PERMISSION" property specifies the actual
permission being set. The "SCOPE" property identifies the
calendar store properties, calendar properties, components, or
properties to which the access right applies. The "RESTRICTION"
property specifies restrictions on commands and results. If the
command does not match the restrictions, or if the results of the
command do not match the restrictions, then it is an access
violation.
9.5. VREPLY Component
Component Name: "VREPLY"
Purpose: Provide a grouping of arbitrary properties and components
that are the data set result from an issued command.
Formal Definition: A "VREPLY" component is defined by the following
notation:
replyc = "BEGIN" ":" "VREPLY" CRLF
any-prop-or-comp
"END" ":" "VREPLY" CRLF
;
any-prop-or-comp = ; Zero or more iana or experimental
; properties and components, in any order.
Description: Provide a grouping of arbitrary properties and
components that are the data set result from an issued command.
A query can return a predictable set of arbitrary properties and
components. This component is used by query and other commands to
return data that does not fit into any other component. It may
contain any valid property or component, even if they are not
registered.
9.6. VQUERY Component
Component Name: VQUERY
Purpose: A component describes a set of objects to be acted upon.
Royer, et al. Experimental [Page 83]
RFC 4324 Calendar Access Protocol December 2005
Formal Definition: A "VQUERY" component is defined by the following
notation:
queryc = "BEGIN" ":" "VQUERY" CRLF
queryprop
"END" ":" "VCAR" CRLF
;
queryprop = 1*(
;
; 'queryid' is OPTIONAL but MUST NOT occur
; more than once. If the "TARGET" property
; is supplied then the "QUERYID" property
; MUST be supplied.
;
queryid / target
;
; 'expand' is OPTIONAL but MUST NOT occur
; more than once.
;
expand
;
; the following are OPTIONAL, and MAY occur
; more than once
;
/ name / other-props
;
; the following MUST occur at least once if
; queryid is not supplied.
;
/ query
)
Description: A "VQUERY" contains properties that describe which
properties and components the CS is requested to act upon.
The "QUERYID" property specifies the local identifier for a
"VQUERY" component.
For a search, if the "TARGET" property is supplied in a "VQUERY"
component, then the CS is to search for the query in the CALID
supplied by the "TARGET" property value.
For a create, the "TARGET" property MUST NOT be supplied because
the destination container is already supplied in the "TARGET"
property of the "VCALENDAR" component.
Examples: see Section 6.1.1.
quot; mailboxes as returned by the LIST
(SUBSCRIBED) command. This command returns a tagged OK response if
the subscription is successful or if the mailbox is already
subscribed.
A server MAY validate the mailbox argument to SUBSCRIBE to verify
that it exists. However, it SHOULD NOT unilaterally remove an
existing mailbox name from the subscription list even if a mailbox by
that name no longer exists.
Note: This requirement is because a server site can choose to
routinely remove a mailbox with a well-known name (e.g., "system-
alerts") after its contents expire, with the intention of
recreating it when new contents are appropriate.
Example: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed
6.3.8. UNSUBSCRIBE Command
Arguments: mailbox name
Responses: no specific responses for this command
Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid
The UNSUBSCRIBE command removes the specified mailbox name from the
server's set of "active" or "subscribed" mailboxes as returned by the
LIST (SUBSCRIBED) command. This command returns a tagged OK response
if the unsubscription is successful or if the mailbox is not
subscribed.
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed
6.3.9. LIST Command
Arguments (basic): reference name
mailbox name with possible wildcards
Arguments (extended): selection options (OPTIONAL)
reference name
Melnikov & Leiba Expires January 30, 2021 [Page 44]
Internet-Draft IMAP4rev2 July 2020
mailbox patterns
return options (OPTIONAL)
Responses: untagged responses: LIST
Result: OK - list completed
NO - list failure: can't list that reference or name
BAD - command unknown or arguments invalid
The LIST command returns a subset of names from the complete set of
all names available to the client. Zero or more untagged LIST
replies are returned, containing the name attributes, hierarchy
delimiter, name, and possible extension information; see the
description of the LIST reply for more detail.
The LIST command SHOULD return its data quickly, without undue delay.
For example, it SHOULD NOT go to excess trouble to calculate the
\Marked or \Unmarked status or perform other processing; if each name
requires 1 second of processing, then a list of 1200 names would take
20 minutes!
The extended LIST command, originally introduced in [RFC5258],
provides capabilities beyond that of the original IMAP LIST command.
The extended syntax is being used if one or more of the following
conditions is true:
1. if the first word after the command name begins with a
parenthesis ("LIST selection options");
2. if the second word after the command name begins with a
parenthesis;
3. if the LIST command has more than 2 parameters ("LIST return
options")
An empty ("" string) reference name argument indicates that the
mailbox name is interpreted as by SELECT. The returned mailbox names
MUST match the supplied mailbox name pattern(s). A non-empty
reference name argument is the name of a mailbox or a level of
mailbox hierarchy, and indicates the context in which the mailbox
name is interpreted. Clients SHOULD use the empty reference
argument.
In the basic syntax only, an empty ("" string) mailbox name argument
is a special request to return the hierarchy delimiter and the root
name of the name given in the reference. The value returned as the
root MAY be the empty string if the reference is non-rooted or is an
empty string. In all cases, a hierarchy delimiter (or NIL if there
Melnikov & Leiba Expires January 30, 2021 [Page 45]
Internet-Draft IMAP4rev2 July 2020
is no hierarchy) is returned. This permits a client to get the
hierarchy delimiter (or find out that the mailbox names are flat)
even when no mailboxes by that name currently exist.
In the extended syntax, any mailbox name arguments that are empty
strings are ignored. There is no special meaning for empty mailbox
names when the extended syntax is used.
The reference and mailbox name arguments are interpreted into a
canonical form that represents an unambiguous left-to-right
hierarchy. The returned mailbox names will be in the interpreted
form, that we call "canonical LIST pattern" later in this document.
To define the term "canonical LIST pattern" formally: it refers to
the canonical pattern constructed internally by the server from the
reference and mailbox name arguments.
Note: The interpretation of the reference argument is
implementation-defined. It depends upon whether the server
implementation has a concept of the "current working directory"
and leading "break out characters", which override the current
working directory.
For example, on a server which exports a UNIX or NT filesystem,
the reference argument contains the current working directory, and
the mailbox name argument would contain the name as interpreted in
the current working directory.
If a server implementation has no concept of break out characters,
the canonical form is normally the reference name appended with
the mailbox name. Note that if the server implements the
namespace convention (Section 5.1.2.1), "#" is a break out
character and must be treated as such.
If the reference argument is not a level of mailbox hierarchy
(that is, it is a \NoInferiors name), and/or the reference
argument does not end with the hierarchy delimiter, it is
implementation-dependent how this is interpreted. For example, a
reference of "foo/bar" and mailbox name of "rag/baz" could be
interpreted as "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/
baz". A client SHOULD NOT use such a reference argument except at
the explicit request of the user. A hierarchical browser MUST NOT
make any assumptions about server interpretation of the reference
unless the reference is a level of mailbox hierarchy AND ends with
the hierarchy delimiter.
Any part of the reference argument that is included in the
interpreted form SHOULD prefix the interpreted form. It SHOULD also
be in the same form as the reference name argument. This rule
Melnikov & Leiba Expires January 30, 2021 [Page 46]
Internet-Draft IMAP4rev2 July 2020
permits the client to determine if the returned mailbox name is in
the context of the reference argument, or if something about the
mailbox argument overrode the reference argument. Without this rule,
the client would have to have knowledge of the server's naming
semantics including what characters are "breakouts" that override a
naming context.
For example, here are some examples of how references
and mailbox names might be interpreted on a UNIX-based
server:
Reference Mailbox Name Interpretation
------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/%
#news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/foo
archive/ ~fred/Mail/* ~fred/Mail/*
The first three examples demonstrate interpretations in
the context of the reference argument. Note that
"~smith/Mail" SHOULD NOT be transformed into something
like "/u2/users/smith/Mail", or it would be impossible
for the client to determine that the interpretation was
in the context of the reference.
The character "*" is a wildcard, and matches zero or more characters
at this position. The character "%" is similar to "*", but it does
not match a hierarchy delimiter. If the "%" wildcard is the last
character of a mailbox name argument, matching levels of hierarchy
are also returned. If these levels of hierarchy are not also
selectable mailboxes, they are returned with the \Noselect mailbox
name attribute (see the description of the LIST response for more
details).
Any syntactically valid pattern that is not accepted by a server for
any reason MUST be silently ignored. I.e. it results in no LIST
responses and the LIST command still returns tagged OK response.
Selection options tell the server to limit the mailbox names that are
selected by the LIST operation. If selection options are used, the
mailboxes returned are those that match both the list of canonical
LIST patterns and the selection options. Unless a particular
selection option provides special rules, the selection options are
cumulative: a mailbox that matches the mailbox patterns is selected
only if it also matches all of the selection options. (An example of
a selection option with special rules is the RECURSIVEMATCH option.)
Melnikov & Leiba Expires January 30, 2021 [Page 47]
Internet-Draft IMAP4rev2 July 2020
Return options control what information is returned for each matched
mailbox. Return options MUST NOT cause the server to report
information about additional mailbox names other than those that
match the canonical LIST patterns and selection options. If no
return options are specified, the client is only expecting
information about mailbox attributes. The server MAY return other
information about the matched mailboxes, and clients MUST be able to
handle that situation.
Initial selection options and return options are defined in the
following subsections, and new ones will also be defined in
extensions. Initial options defined in this document MUST be
supported. Each non-initial option will be enabled by a capability
string (one capability may enable multiple options), and a client
MUST NOT send an option for which the server has not advertised
support. A server MUST respond to options it does not recognize with
a BAD response. The client SHOULD NOT specify any option more than
once; however, if the client does this, the server MUST act as if it
received the option only once. The order in which options are
specified by the client is not significant.
In general, each selection option except RECURSIVEMATCH will have a
corresponding return option with the same name. The REMOTE selection
option is an anomaly in this regard, and does not have a
corresponding return option. That is because it expands, rather than
restricts, the set of mailboxes that are returned. Future extensions
to this specification should keep this parallelism in mind and define
a pair of corresponding selection and return options.
Server implementations are permitted to "hide" otherwise accessible
mailboxes from the wildcard characters, by preventing certain
characters or names from matching a wildcard in certain situations.
For example, a UNIX-based server might restrict the interpretation of
"*" so that an initial "/" character does not match.
The special name INBOX is included in the output from LIST, if INBOX
is supported by this server for this user and if the uppercase string
"INBOX" matches the interpreted reference and mailbox name arguments
with wildcards as described above. The criteria for omitting INBOX
is whether SELECT INBOX will return failure; it is not relevant
whether the user's real INBOX resides on this or some other server.
6.3.9.1. LIST Selection Options
The selection options defined in this specification are as follows:
SUBSCRIBED - causes the LIST command to list subscribed names,
rather than the existing mailboxes. This will often be a subset
Melnikov & Leiba Expires January 30, 2021 [Page 48]
Internet-Draft IMAP4rev2 July 2020
of the actual mailboxes. It's also possible for this list to
contain the names of mailboxes that don't exist. In any case, the
list MUST include exactly those mailbox names that match the
canonical list pattern and are subscribed to.
This option defines a mailbox attribute, "\Subscribed", that
indicates that a mailbox name is subscribed to. The "\Subscribed"
attribute MUST be supported and MUST be accurately computed when
the SUBSCRIBED selection option is specified.
Note that the SUBSCRIBED selection option implies the SUBSCRIBED
return option (see below).
REMOTE - causes the LIST command to show remote mailboxes as well as
local ones, as described in [RFC2193]. This option is intended to
replace the RLIST command and, in conjunction with the SUBSCRIBED
selection option, the RLSUB command. Servers that don't support
remote mailboxes just ignore this option.
This option defines a mailbox attribute, "\Remote", that indicates
that a mailbox is a remote mailbox. The "\Remote" attribute MUST
be accurately computed when the REMOTE option is specified.
The REMOTE selection option has no interaction with other options.
Its effect is to tell the server to apply the other options, if
any, to remote mailboxes, in addition to local ones. In
particular, it has no interaction with RECURSIVEMATCH (see below).
A request for (REMOTE RECURSIVEMATCH) is invalid, because a
request for (RECURSIVEMATCH) is also invalid. A request for
(REMOTE RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed
mailboxes, both local and remote.
RECURSIVEMATCH - this option forces the server to return information
about parent mailboxes that don't match other selection options,
but have some submailboxes that do. Information about children is
returned in the CHILDINFO extended data item, as described in
Section 6.3.9.6.
Note 1: In order for a parent mailbox to be returned, it still has
to match the canonical LIST pattern.
Note 2: When returning the CHILDINFO extended data item, it
doesn't matter whether or not the submailbox matches the canonical
LIST pattern. See also example 9 in Section 6.3.9.8.
The RECURSIVEMATCH option MUST NOT occur as the only selection
option (or only with REMOTE), as it only makes sense when other
Melnikov & Leiba Expires January 30, 2021 [Page 49]
Internet-Draft IMAP4rev2 July 2020
selection options are also used. The server MUST return BAD
tagged response in such case.
Note that even if the RECURSIVEMATCH option is specified, the
client MUST still be able to handle a case when a CHILDINFO
extended data item is returned and there are no submailboxes that
meet the selection criteria of the subsequent LIST command, as
they can be deleted/renamed after the LIST response was sent, but
before the client had a chance to access them.
6.3.9.2. LIST Return Options
The return options defined in this specification are as follows:
SUBSCRIBED - causes the LIST command to return subscription state
for all matching mailbox names. The "\Subscribed" attribute MUST
be supported and MUST be accurately computed when the SUBSCRIBED
return option is specified. Further, all mailbox flags MUST be
accurately computed (this differs from the behavior of the
obsolete LSUB command from IMAP4rev1).
CHILDREN - requests mailbox child information as originally proposed
in [RFC3348]. See Section 6.3.9.5, below, for details. This
option MUST be supported by all servers.
STATUS - requests STATUS response for each matching mailbox.
This option takes STATUS data items as parameters. For each
selectable mailbox matching the list pattern and selection
options, the server MUST return an untagged LIST response
followed by an untagged STATUS response containing the
information requested in the STATUS return option, except for
some cases described below.
If an attempted STATUS for a listed mailbox fails because the
mailbox can't be selected (e.g., if the "l" ACL right [RFC4314]
is granted to the mailbox and the "r" right is not granted, or
due to a race condition between LIST and STATUS changing the
mailbox to \NoSelect), the STATUS response MUST NOT be returned
and the LIST response MUST include the \NoSelect attribute.
This means the server may have to buffer the LIST reply until
it has successfully looked up the necessary STATUS information.
If the server runs into unexpected problems while trying to
look up the STATUS information, it MAY drop the corresponding
STATUS reply. In such a situation, the LIST command would
still return a tagged OK reply.
Melnikov & Leiba Expires January 30, 2021 [Page 50]
Internet-Draft IMAP4rev2 July 2020Royer, et al. Experimental [Page 84]
RFC 4324 Calendar Access Protocol December 2005
10. Commands and Responses
CAP commands and responses are described in this section.
10.1. CAP Commands (CMD)
All commands are sent using the CMD property.
Property Name: CMD
Purpose: This property defines the command to be sent.
Value Type: TEXT
Property Parameters: Non-standard, id, localize, latency, action or
options.
Conformance: This property is the method used to specify the commands
to a CS; it can exist in any object sent to the CS.
Description: All of the commands to the CS are supplied in this
property. The "OPTIONS" parameter is overloaded and its meaning
is dependent on the CMD value supplied.
Formal Definition: The property is defined by the following
notation:
cmd = "CMD" (
abort-cmd
/ continue-cmd
/ create-cmd
/ delete-cmd
/ generate-uid-cmd
/ get-capability-cmd
/ identify-cmd
/ modify-cmd
/ move-cmd
/ reply-cmd
/ search-cmd
/ set-locale-cmd
/ iana-cmd
/ x-cmd
) CRLF
;
option-value = "OPTION" "=" paramtext
;
paramtext ; As defined in [iCAL].
Royer, et al. Experimental [Page 85]
RFC 4324 Calendar Access Protocol December 2005
Calendaring commands allow a CUA to directly manipulate a calendar.
Calendar access rights can be granted or denied for any commands.
10.1.1. Bounded Latency
A CAP command can have an associated maximum latency time by
specifying the "LATENCY" parameter. If the command is unable to be
completed in the specified amount of time (as specified by the
"LATENCY" parameter value with an "ACTION" parameter set to the "ASK"
value), then a "TIMEOUT" command MUST be sent on the same channel".
The reply MUST be a an "ABORT" or a "CONTINUE" command. If the CUA
initiated the original command, then the CS would issue the "TIMEOUT"
command and the CUA would then have to issue an "ABORT" or "CONTINUE"
command. If the CS initiated the original command then the CUA would
have to issue the "TIMEOUT" and the CS would send the "ABORT" or
"CONTINUE".
Upon receiving an "ABORT" command, the command must then be
terminated. Only the "ABORT", "TIMEOUT", "REPLY, and "CONTINUE"
commands cannot be aborted. The "ABORT", "TIMEOUT", and "REPLY"
commands MUST NOT have latency set.
Upon receiving a "CONTINUE" command the work continues as if it had
not been delayed or stopped. Note that a new latency time MAY be
included in a "CONTINUE" command indicating to continue the original
command until the "LATENCY" parameter value expires or the results of
the original command can be returned.
Both the "LATENCY" parameter and the "ACTION" parameter MUST be
supplied to any "CMD" property, or nether can be added to the "CMD"
property. The "LATENCY" parameter MUST be set to the maximum latency
time in seconds. The "ACTION" parameter accepts the following
values: "ASK" and "ABORT" parameters.
If the maximum latency time is exceeded and the "ACTION" parameter is
set to the "ASK" value, then "TIMEOUT" command MUST be sent.
Otherwise, if the "ACTION" parameter is set to the "ABORT" value,
then the command MUST be terminated and return a REQUEST-STATUS code
of 2.0.3 for the original command.
If a CS can both start sending the reply to a command and guarantee
that all of the results can be sent from a command (short of
something like network or power failure) prior to the "LATENCY"
timeout value, then the "LATENCY" time has not expired.
Example:
Royer, et al. Experimental [Page 86]
RFC 4324 Calendar Access Protocol December 2005
In this example the initiator asks for the listeners capabilities.
I: Content-Type: text/calendar
I:
I: BEGIN:VCALENDAR
I: VERSION:2.0
I: PRODID:The CUA's PRODID
I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY
I: END:VCALENDAR
# After 3 seconds
L: Content-Type: text/calendar
L:
L: BEGIN:VCALENDAR
L: PRODID:-//someone's prodid
L: VERSION:2.0
L: CMD;ID=xyz12346:TIMEOUT
L: END:VCALENDAR
In order to continue and give the CS more time, the CUA would issue a
"CONTINUE" command:
I: Content-Type: text/calendar
I:
I: BEGIN:VCALENDAR
I: VERSION:2.0
I: PRODID:-//someone's prodid
I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:CONTINUE
I: END:VCALENDAR
L: Content-Type: text/calendar
L:
L: BEGIN:VCALENDAR
L: VERSION:2.0
L: PRODID:-//someone's prodid
L: CMD;ID=xyz12346:REPLY
L: BEGIN:VREPLY
L: REQUEST-STATUS:2.0.3;Continued for 3 more seconds
L: END:VREPLY
L: END:VCALENDAR
Here the "2.0.3" status is returned because it is not an error, it is
a progress status sent in reply to the "CONTINUE" command.
To abort the command and not wait any further, issue an "ABORT"
command:
Royer, et al. Experimental [Page 87]
RFC 4324 Calendar Access Protocol December 2005
I: Content-Type: text/calendar
I:
I: BEGIN:VCALENDAR
I: VERSION:2.0
I: PRODID:-//someone's prodid
I: CMD;ID=xyz12346:ABORT
I: END:VCALENDAR
# Which would result in a 2.0.3 reply.
L: Content-Type: text/calendar
L:
L: BEGIN:VCALENDAR
L: VERSION:2.0
L: PRODID:-//someone's prodid
L: CMD;ID=xyz12346:REPLY
L: BEGIN:VREPLY
L: REQUEST-STATUS:2.0.3;Aborted As Requested.
L: END:VREPLY
L: END:VCALENDAR
If the "ACTION" value had been set to "ABORT", then the listner would
send a "7.0" error on timeout in the reply to the command that
initiated the command that timed out.
10.2. ABORT Command
CMD: ABORT
Purpose: The "ABORT" command is sent to request that the named or the
only in-process command be aborted. Latency MUST not be supplied
with the "ABORT" command.
Formal Definition: An "ABORT" command is defined by the following
notation:
Royer, et al. Experimental [Page 88]
RFC 4324 Calendar Access Protocol December 2005
abort-cmd = abortparam ":" "ABORT"
;
abortparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
The REPLY of any "ABORT" command is:
abort-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops
abort-vreply
"END" ":" "VCALENDAR" CRLF
;
abort-vreply = "BEGIN" ":" "VREPLY" CRLF
rstatus
other-props
"END" ":" "VREPLY" CRLF
10.3. CONTINUE Command
CMD: CONTINUE
Purpose: The "CONTINUE" command is only sent after a "TIMEOUT"
command has been received to inform the other end of the session
to resume working on a command.
Formal Definition: A "CONTINUE" command is defined by the following
notation:
continue-cmd = continueparam ":" "CONTINUE"
;
continueparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
Royer, et al. Experimental [Page 89]
RFC 4324 Calendar Access Protocol December 2005
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following are optional,
; and MAY occur more than once
;
/ other-params
)
The REPLY of any "CONTINUE" command is:
continue-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops
continue-vreply
"END" ":" "VCALENDAR" CRLF
;
continue-vreply = "BEGIN" ":" "VREPLY" CRLF
rstatus
other-props
"END" ":" "VREPLY" CRLF
10.4. CREATE Command
CMD: CREATE
Purpose: The "CREATE" command is used to create one or more
iCalendar objects in the store in the "BOOKED" or "UNPROCESSED"
state.
A CUA MAY send a "CREATE" command to a CS. The "CREATE" command
MUST be implemented by all CSs.
The CS MUST NOT send a "CREATE" command to any CUA.
Formal Definition: A "CREATE" command is defined by the following
notation and the hierarchy restrictions, as defined in Section
3.2:
create-cmd = createparam ":" "CREATE"
;
createparam = *(
;
Royer, et al. Experimental [Page 90]
RFC 4324 Calendar Access Protocol December 2005
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
Response:
One iCalendar object per TARGET property MUST be returned.
The REPLY of any "CREATE" command is limited to the restriction
tables defined in [iTIP] for iTIP objects, in addition to this
ABNF:
Royer, et al. Experimental [Page 91]
RFC 4324 Calendar Access Protocol December 2005
create-reply = "BEGIN" ":" "VCALENDAR" CRLF
creply-props
1*(create-vreply)
"END" ":" "VCALENDAR" CRLF
;
create-vreply = "BEGIN" ":" "VREPLY" CRLF
created-id
rstatus
other-props
"END" ":" "VREPLY" CRLF
;
; Where the id is appropriate for the
; type of object created:
;
; VAGENDA = relcalid
; VALARM = sequence
; VCAR = carid
; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
; VQUERY = queryid
; VTIMEZONE = tzid
; x-comp = x-id
;
created-id = ( relcalid / carid / uid / queryid /
tzid / sequence / x-id)
;
tzid = ; As defined in [iCAL].
;
sequence = ; As defined in [iCAL].
;
uid = ; As defined in [iCAL].
;
x-id = ; An ID for an x-component.
;
creply-props = 4*(
; These are REQUIRED and MUST NOT occur
; more than once.
;
prodid /version / target / reply-cmd
;
; These are optional, and may occur more
; than once.
;
other-props )
For a "CREATE" command, the "TARGET" property specifies the
containers where the components will be created.
Royer, et al. Experimental [Page 92]
RFC 4324 Calendar Access Protocol December 2005
If the iCalendar object being created does not have a "METHOD"
property, then its state is "BOOKED" and it is not an [iTIP]
scheduling object. Use the "DELETE" command to set the state of
an object to the "DELETED" state (tagged for deletion). A CUA
cannot use the "CREATE" command to create an object in the
"DELETED" state.
If the intention is to book an [iTIP] object, then the "METHOD"
property MUST NOT be supplied. Otherwise, any [iTIP] object MUST
have a valid [iTIP] "METHOD" property value and it is a scheduling
request being deposited into the CS with its state set to
"UNPROCESSED".
Format Definition: ABNF for a "CREATE" object is:
create-object = "BEGIN" ":" "VCALENDAR" CRLF
; If 'calprops' contain the "METHOD" property
; then this 'create-object' component MUST
; conform to [iTIP] restrictions.
;
; calprops MUST include 'create-cmd'
;
calprops
other-props
1*(create-comp)
"END" ":" "VCALENDAR" CRLF
; NOTE: The 'VCALSTORE' component is not included in
; 'create-comp' as it is out of scope for CAP to create
; a new CS.
;
create-comp = agendac / carc / queryc
/ timezonec / freebusyc
/ eventc / todoc / journalc
/ iana-comp / x-comp
;
freebusyc = ; As defined in [iCAL].
;
eventc = ; As defined in [iCAL].
;
journalc = ; As defined in [iCAL].
;
timezonec = ; As defined in [iCAL].
;
todoc = ; As defined in [iCAL].
In the following example, two new top level "VAGENDA" components are
created. Note that the "CSID" value of the server is
Royer, et al. Experimental [Page 93]
RFC 4324 Calendar Access Protocol December 2005
cal.example.com, which is where the new "VAGENDA" components are
going to be created.
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: PRODID:-//someone's prodid
C: VERSION:2.0
C: CMD;ID=creation01:CREATE
C: TARGET:cal.example.com
C: BEGIN:VAGENDA <- data for 1st new calendar
C: CALID:relcalz1
C: NAME;LANGUAGE=en_US:Bill's Soccer Team
C: OWNER:bill
C: CALMASTER:mailto:bill@example.com
C: TZID:US/Pacific
C: END:VAGENDA
C: BEGIN:VAGENDA <- data for 2nd new calendar
C: CALID:relcalz2
C: NAME;LANGUAGE=EN-us:Mary's personal calendar
C: OWNER:mary
C: CALMASTER:mailto:mary@example.com
C: TZID:US/Pacific
C: END:VAGENDA
C: END:VCALENDAR
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=creation01:REPLY
S: TARGET:cal.example.com
S: BEGIN:VREPLY <- Reply for 1st calendar create
S: CALID:relcalz1
S: REQUEST-STATUS:2.0
S: END:REPLY
S: BEGIN:VREPLY <- Reply for 2nd calendar create
S: CALID:relcalz2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
To create a new component in multiple containers, simply name all
of the containers in the "TARGET" in the create command. A new
"VEVENT" component is created in two TARGET components. In this
example, the "VEVENT" component is one new [iTIP] "REQUEST" to be
Royer, et al. Experimental [Page 94]
RFC 4324 Calendar Access Protocol December 2005
stored in two calendars. The results would be iCalendar objects
that conform to the [iTIP] replies as defined in [iTIP].
This example shows two [iTIP] "VEVENT" components being created in
each of the two supplied "TARGET&
6.3.9.3. General Principles for Returning LIST Responses
This section outlines several principles that can be used by server
implementations of this document to decide whether a LIST response
should be returned, as well as how many responses and what kind of
information they may contain.
1. At most one LIST response should be returned for each mailbox
name that matches the canonical LIST pattern. Server
implementors must not assume that clients will be able to
assemble mailbox attributes and other information returned in
multiple LIST responses.
2. There are only two reasons for including a matching mailbox name
in the responses to the LIST command (note that the server is
allowed to return unsolicited responses at any time, and such
responses are not governed by this rule):
A. The mailbox name also satisfies the selection criteria.
B. The mailbox name doesn't satisfy the selection criteria, but
it has at least one descendant mailbox name that satisfies
the selection criteria and that doesn't match the canonical
LIST pattern.
For more information on this case, see the CHILDINFO extended
data item described in Section 6.3.9.6. Note that the
CHILDINFO extended data item can only be returned when the
RECURSIVEMATCH selection option is specified.
3. Attributes returned in the same LIST response must be treated
additively. For example, the following response
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed.
6.3.9.4. Additional LIST-related Requirements on Clients
All clients MUST treat a LIST attribute with a stronger meaning as
implying any attribute that can be inferred from it. (See
Section 7.2.3 for the list of currently defined attributes). For
example, the client must treat the presence of the \NoInferiors
attribute as if the \HasNoChildren attribute was also sent by the
server.
Melnikov & Leiba Expires January 30, 2021 [Page 51]
Internet-Draft IMAP4rev2 July 2020
The following table summarizes inference rules.
+--------------------+-------------------+
| returned attribute | implied attribute |
+--------------------+-------------------+
| \NoInferiors | \HasNoChildren |
| \NonExistent | \NoSelect |
+--------------------+-------------------+
6.3.9.5. The CHILDREN Return Option
The CHILDREN return option is simply an indication that the client
wants information about whether or not mailboxes contain children
mailboxes; a server MAY provide it even if the option is not
specified.
Many IMAP4 clients present to the user a hierarchical view of the
mailboxes that a user has access to. Rather than initially
presenting to the user the entire mailbox hierarchy, it is often
preferable to show to the user a collapsed outline list of the
mailbox hierarchy (particularly if there is a large number of
mailboxes). The user can then expand the collapsed outline hierarchy
as needed. It is common to include within the collapsed hierarchy a
visual clue (such as a ''+'') to indicate that there are child
mailboxes under a particular mailbox. When the visual clue is
clicked, the hierarchy list is expanded to show the child mailboxes.
The CHILDREN return option provides a mechanism for a client to
efficiently determine whether a particular mailbox has children,
without issuing a LIST "" * or a LIST "" % for each mailbox name.
The CHILDREN return option defines two new attributes that MUST be
returned within a LIST response: \HasChildren and \HasNoChildren.
Although these attributes MAY be returned in response to any LIST
command, the CHILDREN return option is provided to indicate that the
client particularly wants this information. If the CHILDREN return
option is present, the server MUST return these attributes even if
their computation is expensive.
\HasChildren
The presence of this attribute indicates that the mailbox has
child mailboxes. A server SHOULD NOT set this attribute if
there are child mailboxes and the user does not have permission
to access any of them. In this case, \HasNoChildren SHOULD be
used. In many cases, however, a server may not be able to
efficiently compute whether a user has access to any child
mailbox. Note that even though the \HasChildren attribute for a
mailbox must be correct at the time of processing of the
mailbox, a client must be prepared to deal with a situation when
Melnikov & Leiba Expires January 30, 2021 [Page 52]
Internet-Draft IMAP4rev2 July 2020
a mailbox is marked with the \HasChildren attribute, but no
child mailbox appears in the response to the LIST command. This
might happen, for example, due to children mailboxes being
deleted or made inaccessible to the user (using access control)
by another client before the server is able to list them.
\HasNoChildren
The presence of this attribute indicates that the mailbox has NO
child mailboxes that are accessible to the currently
authenticated user.
It is an error for the server to return both a \HasChildren and a
\HasNoChildren attribute in the same LIST response.
Note: the \HasNoChildren attribute should not be confused with the
the \NoInferiors attribute, which indicates that no child mailboxes
exist now and none can be created in the future.
6.3.9.6. CHILDINFO Extended Data Item
The CHILDINFO extended data item MUST NOT be returned unless the
client has specified the RECURSIVEMATCH selection option.
The CHILDINFO extended data item in a LIST response describes the
selection criteria that has caused it to be returned and indicates
that the mailbox has at least one descendant mailbox that matches the
selection criteria.
Note: Some servers allow for mailboxes to exist without requiring
their parent to exist. For example, a mailbox "Customers/ABC" can
exist while the mailbox "Customers" does not. As CHILDINFO extended
data item is not allowed if the RECURSIVEMATCH selection option is
not specified, such servers SHOULD use the "\NonExistent
\HasChildren" attribute pair to signal to the client that there is a
descendant mailbox that matches the selection criteria. See example
11 in Section 6.3.9.8.
The returned selection criteria allow the client to distinguish a
solicited response from an unsolicited one, as well as to distinguish
among solicited responses caused by multiple pipelined LIST commands
that specify different criteria.
Servers SHOULD ONLY return a non-matching mailbox name along with
CHILDINFO if at least one matching child is not also being returned.
That is, servers SHOULD suppress redundant CHILDINFO responses.
Melnikov & Leiba Expires January 30, 2021 [Page 53]
Internet-Draft IMAP4rev2 July 2020
Examples 8 and 10 in Section 6.3.9.8 demonstrate the difference
between present CHILDINFO extended data item and the "\HasChildren"
attribute.
The following table summarizes interaction between the "\NonExistent"
attribute and CHILDINFO (the first column indicates whether the
parent mailbox exists):
+--------+-------------+------------------+-------------------------+
| exists | meets the | has a child that | returned |
| | selection | meets the | IMAP4rev2/LIST-EXTENDED |
| | criteria | selection | attributes and |
| | | criteria | CHILDINFO |
+--------+-------------+------------------+-------------------------+
| no | no | no | no LIST response |
| | | | returned |
| yes | no | no | no LIST response |
| | | | returned |
| no | yes | no | (\NonExistent <attr>) |
| yes | yes | no | (<attr>) |
| no | no | yes | (\NonExistent) + |
| | | | CHILDINFO |
| yes | no | yes | () + CHILDINFO |
| no | yes | yes | (\NonExistent <attr>) + |
| | | | CHILDINFO |
| yes | yes | yes | (<attr>) + CHILDINFO |
+--------+-------------+------------------+-------------------------+
where <attr> is one or more attributes that correspond to the
selection criteria; for example, for the SUBSCRIBED option the <attr>
is \Subscribed.
6.3.9.7. OLDNAME Extended Data Item
The OLDNAME extended data item is included when a mailbox name is
created (with CREATE command), renamed (with RENAME command) or
deleted (with DELETE command). (When a mailbox is deleted the
" properties. As it contains the
"METHOD" property, they will be stored in the "UNPROCESSED" state:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=creation02:CREATE
C: METHOD:REQUEST
C: TARGET:relcalz1
C: TARGET:relcalz2
C: BEGIN:VEVENT
C: DTSTART:20030307T180000Z
C: UID:FirstInThisExample-1
C: DTEND:20030307T190000Z
C: SUMMARY:Important Meeting
C: END:VEVENT
C: BEGIN:VEVENT
C: DTSTART:20040307T180000Z
C: UID:SecondInThisExample-2
C: DTEND:20040307T190000Z
C: SUMMARY:Important Meeting
C: END:VEVENT
C: END:VCALENDAR
The CS sends the "VREPLY" commands in separate MIME objects, one
per supplied "TARGET" property value.
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=creation02:REPLY
S: TARGET:relcalz1 <- 1st TARGET listed.
S: BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET.
S: UID:FirstInThisExample-1
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET.
S: UID:SecondInThisExample-2
S: REQUEST-STATUS:2.0
S: END:VREPLY
Royer, et al. Experimental [Page 95]
RFC 4324 Calendar Access Protocol December 2005
S: END:VCALENDAR
And the second reply for the 2nd TARGET:
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=creation02:REPLY
S: TARGET:relcalz2 <- 2nd TARGET listed
S: BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET.
S: UID:FirstInThisExample-1
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET.
S: UID:SecondInThisExample-2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
10.5. DELETE Command
CMD: DELETE
Purpose: The "DELETE" command physically removes the QUERY result
from the store or marks it for deletion.
A CUA MAY send a "DELETE" command to a CS. The "DELETE" command
MUST be implemented by all CSs.
The CS MUST NOT send a "DELETE" command to any CUA.
Formal Definition: A "DELETE" command is defined by the following
notation:
delete-cmd = deleteparam ":" "DELETE"
;
deleteparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
/ option-param "MARK"
;
Royer, et al. Experimental [Page 96]
RFC 4324 Calendar Access Protocol December 2005
; The following MUST occur exactly once and
; only when the latency-param has been supplied.
; It MUST NOT be supplied if the latency-param
; is not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
The "DELETE" command is used to delete calendars or components.
The included "VQUERY" component(s) specifies the container(s) to
delete.
To mark a component for delete without physically removing it,
include the "OPTIONS" parameter with its value set to the "MARK"
value in order to alter its state to "DELETED".
When components are deleted, only the top-most component
"REQUEST-STATUS" properties are returned. No "REQUEST-STATUS"
properties are returned for components inside of the selected
components. There MUST be one "VREPLY" component returned for
each object that is deleted or marked for delete. Note that if no
"VREPLY" components are returned, then nothing matched and nothing
was deleted.
Restriction Table for the "REPLY" command for any "DELETE"
command.
delete-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops ; MUST include 'reply-cmd'
*(delete-vreply)
"END" ":" "VCALENDAR" CRLF
;
delete-vreply = "BEGIN" ":" "VREPLY" CRLF
deleted-id
rstatus
"END" ":" "VREPLY" CRLF
;
; Where the id is appropriate for the
; type of object deleted:
;
; VAGENDA = relcalid
; VCAR = carid
; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
Royer, et al. Experimental [Page 97]
RFC 4324 Calendar Access Protocol December 2005
; VQUERY = queryid
; ALARM = sequence
; VTIMEZONE = tzid
; x-comp = x-id
; An instance = uid recurid
;
deleted-id = ( relcalid / carid / uid / uid recurid
/ queryid / tzid / sequence / x-id )
Example: to delete a "VEVENT" component with "UID" value of
"abcd12345" from the calendar "relcalid-22" from the current CS:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: TARGET:relcalid-22
C: CMD;ID:"random but unique per CUA":DELETE
C: BEGIN:VQUERY
C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345'
C: END:VQUERY
C: END:VCALENDAR
S: BEGIN:VCALENDAR
S: TARGET:relcalid-22
S: CMD;ID:"random but unique per CUA":REPLY
S: BEGIN:VREPLY
S: UID:abcd12345
S: REQUEST-STATUS:3.0
S: END:VREPLY
S: END:VCALENDAR
One or more iCalendar objects will be returned that contain
"REQUEST-STATUS" properties for the deleted components. More than
one component could have been deleted. Any booked component and
any number of unprocessed [iTIP] scheduling components that
matched the QUERY value in the above example will be returned.
Each unique "METHOD" property value that was deleted from the
store MUST be in a separate iCalendar object. This is because
only one "METHOD" property is allowed in a single "VCALENDAR"
BEGIN/END block.
10.6. GENERATE-UID Command
CMD: GENERATE-UID
Purpose: The "GENERATE-UID" command returns one or more unique
identifiers that MUST be globally unique.
Royer, et al. Experimental [Page 98]
RFC 4324 Calendar Access Protocol December 2005
The "GENERATE-UID" command MAY be sent to any CS. The "GENERATE-
UID" command MUST be implemented by all CSs.
The "GENERATE-UID" command MUST NOT be sent to a CUA.
Formal Definition: A "GENERATE-UID" command is defined by the
following notation:
generate-uid-cmd = genuidparam ":" "GENERATE-UID"
;
genuidparam = *(
;
; The following are optional,
; but MUST NOT occur more than once.
;
id-param
/ localize-param
/ latency-param
;
; The following MUST occur exactly once and
; only when the latency-param has been supplied.
; It MUST NOT be supplied if the latency-param
; is not supplied.
;
/ action-param
;
; The following is optional,
; and MAY occur more than once.
;
/ other-params
;
; The following MUST be supplied exactly once.
; The value specifies the number of UIDs to
; be returned.
;
/ option-param posint1
)
Response:
gen-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops ; Which MUST include 'reply-cmd'
1*(gen-vreply)
"END" ":" "VCALENDAR" CRLF
gen-vreply = "BEGIN" ":" "VREPLY" CRLF
1*(uid)
rstatus
Royer, et al. Experimental [Page 99]
RFC 4324 Calendar Access Protocol December 2005
"\NonExistent" attribute is also included.) IMAP extensions can
specify other conditions when OLDNAME extended data item should be
included.
If the server allows de-normalized mailbox names (see Section 5.1) in
SELECT/EXAMINE, CREATE, RENAME or DELETE, it SHOULD return an
unsolicited LIST response that includes OLDNAME extended data item,
whenever the supplied mailbox name differs from the resulting
normalized mailbox name. From the client point of view this is
indistinguishable from another user renaming of deleting the mailbox,
as specified in the previous paragraph.
Melnikov & Leiba Expires January 30, 2021 [Page 54]
Internet-Draft IMAP4rev2 July 2020
A deleted mailbox can be announced like this:
S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox"
Example of a renamed mailbox:
S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
6.3.9.8. LIST Command Examples
This example shows some uses of the basic LIST command:
Example: C: A101 LIST "" ""
S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed
Extended examples:
1: The first example shows the complete local hierarchy that will
be used for the other examples.
C: A01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST () "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST () "/" "Vegetable"
S: * LIST () "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: A01 OK done
2: In the next example, we will see the subscribed mailboxes. This
is similar to, but not equivalent with now deprecated, <LSUB ""
"*"> (see [RFC3501] for more details on LSUB command). Note
that the mailbox called "Fruit/Peach" is subscribed to, but does
not actually exist (perhaps it was deleted while still
subscribed). The "Fruit" mailbox is not subscribed to, but it
Melnikov & Leiba Expires January 30, 2021 [Page 55]
Internet-Draft IMAP4rev2 July 2020
has two subscribed children. The "Vegetable" mailbox is
subscribed and has two children; one of them is subscribed as
well.
C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: A02 OK done
3: The next example shows the use of the CHILDREN option. The
client, without having to list the second level of hierarchy,
now knows which of the top-level mailboxes have submailboxes
(children) and which do not. Note that it's not necessary for
the server to return the \HasNoChildren attribute for the inbox,
because the \NoInferiors attribute already implies that, and has
a stronger meaning.
C: A03 LIST () "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: A03 OK done
4: In this example, we see more mailboxes that reside on another
server. This is similar to the command <RLIST "" "%">.
C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done
5: The following example also requests the server to include
mailboxes that reside on another server. The server returns
information about all mailboxes that are subscribed. This is
similar to the command <RLSUB "" "*"> (see [RFC2193] for more
details on RLSUB). We also see the use of two selection
options.
Melnikov & Leiba Expires January 30, 2021 [Page 56]
Internet-Draft IMAP4rev2 July 2020
C: A05 LIST (REMOTE SUBSCRIBED) "" "*"END" ":" "VREPLY" CRLF
{%%%IS THIS RIGHT%%%?]
Example:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=unique-per-cua-124;OPTIONS=5:GENERATE-UID
C: END:VCALENDAR
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=unique-per-cua-124:REPLY
S: BEGIN:VREPLY
S: UID:20011121T120000Z-12340@cal.example.com
S: UID:20011121T120000Z-12341@cal.example.com
S: UID:20011121T120000Z-12342@cal.example.com
S: UID:20011121T120000Z-12343@cal.example.com
S: UID:20011121T120000Z-12344@cal.example.com
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
10.7. GET-CAPABILITY Command
CMD: GET-CAPABILITY
Purpose: The "GET-CAPABILITY" command returns the capabilities of the
other end point of the session.
A CUA MUST send a "GET-CAPABILITY" command to a CS after the
initial connection. A CS MUST send a "GET-CAPABILITY" command to
a CUA after the initial connection. The "GET-CAPABILITY" command
and reply MUST be implemented by all CSs and CUAs.
Formal Definition: A "GET-CAPABILITY" command is defined by the
following notation:
get-capability-cmd = capabilityparam ":" "GET-CAPABILITY"
capabilityparam = *(
; the following are optional,
; but MUST NOT occur more than once
Royer, et al. Experimental [Page 100]
RFC 4324 Calendar Access Protocol December 2005
;
id-param / localize-param / latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
Response:
The "GET-CAPABILITY" command returns information about the
implementation at the other end of the session. The values
returned may differ depending on current user identify and the
security level of the connection.
Client implementations SHOULD NOT require any capability element
beyond those defined in this specification or future RFC
publications. They MAY ignore any nonstandard, experimental
capability elements. The "GET-CAPABILITY" reply may return
different results, depending on the UPN and if the UPN is
authenticated.
When sending a reply to a "GET-CAPABILITY" command, all of these
MUST be supplied. The following properties are returned in
response to a "GET-CAPABILITY" command:
cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF
; The following properties may be in any order.
;
rodid
version
reply-cmd
other-props
"BEGIN" ":" "VREPLY" CRLF
; The following properties may be in any order.
;
cap-version
car-level
components
Royer, et al. Experimental [Page 101]
RFC 4324 Calendar Access Protocol December 2005
stores-expanded
maxdate
mindate
itip-version
max-comp-size
multipart
query-level
recur-accepted
recur-expand
recur-limit
other-props
"END" ":" "VREPLY" CRLF
"END" ":" "VCALENDAR" CRLF
Example:
I: Content-Type: text/calendar
I:
I: BEGIN:VCALENDAR
I: VERSION:2.0
I: PRODID:-//someone's prodid
I: CMD;ID=unique-per-cua-125:GET-CAPABILITY
I: END:VCALENDAR
L: Content-Type: text/calendar
L:
L: BEGIN:VCALENDAR
L: VERSION:2.0
L: PRODID:-//someone's prodid
L: CMD;ID=unique-per-cua-125:REPLY
L: BEGIN:VREPLY
L: CAP-VERSION:1.0
L: PRODID:The CS prodid
L: QUERY-LEVEL:CAL-QL-1
L: CAR-LEVEL:CAR-FULL-1
L: MAXDATE:99991231T235959Z
L: MINDATE:00000101T000000Z
L: MAX-COMPONENT-SIZE:0
L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR,
L: VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY
L: ITIP-VERSION:2446
L: RECUR-ACCEPTED:TRUE
Royer, et al. Experimental [Page 102]
RFC 4324 Calendar Access Protocol December 2005
L: RECUR-EXPAND:TRUE
L: RECUR-LIMIT:0
L: STORES-EXPANDED:FALSE
L: X-INET-PRIVATE-COMMANDS:1.0
L: END:VREPLY
L: END:VCALENDAR
10.8. IDENTIFY Command
CMD: IDENTIFY
Purpose: The "IDENTIFY" command allows the CUA to set a new identity
to be used for calendar access.
A CUA MAY send an "IDENTIFY" command to a CS. The "IDENTIFY"
command MUST be implemented by all CSs. A CS implementation MAY
reject all "IDENTIFY" commands.
The CS MUST NOT send an "IDENTIFY" command to any CUA.
Formal Definition: An "IDENTIFY" command is defined by the following
notation:
identify-cmd = identifyparam ":" "IDENTIFY"
;
identifyparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
;
; The value is the UPN of the requested
; identity. If option is not supplied it is
Royer, et al. Experimental [Page 103]
RFC 4324 Calendar Access Protocol December 2005
; a request to return to the original
; authenticated identity.
;
/ option-param upn
)
Response:
A "REQUEST-STATUS" property wrapped in a "VREPLY" component with
only one of the following request-status codes:
2.0 Successful.
6.4 Identity not permitted. VCAR restriction.
The CS determines, through an internal mechanism, if the credentials
supplied at authentication permit the operation as the selected
identity. If they do, the session assumes the new identity;
otherwise, a security error is returned.
Example:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY
C: END:VCALENDAR
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: BEGIN:VREPLY
S: REQUEST-STATUS:2.0;Request Approved
S: END:VREPLY
S: END:VCALENDAR
Or if denied:
Royer, et al. Experimental [Page 104]
RFC 4324 Calendar Access Protocol December 2005
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: PRODID:-//someone's prodid
S: VERSION:2.0
S: BEGIN:VREPLY
S: REQUEST-STATUS:6.4;Request Denied
S: END:VREPLY
S: END:VCALENDAR
For the CUA to return to its original authenticated identity, the
OPTIONS parameter is omitted:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=unique-per-cua-995:IDENTIFY
C: END:VCALENDAR
The CS may accept (2.0) or deny (6.4) the request to return to the
original identity.
If a CS considers the "IDENTIFY" command an attempt to violate
security, the CS MAY terminate the [BEEP] session without any further
notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply.
10.9. MODIFY Command
CMD: MODIFY
Purpose: The "MODIFY" command is used to modify existing components.
A CUA MAY send a "MODIFY" command to a CS. The "MODIFY" command
MUST be implemented by all CSs.
The CS MUST NOT send a "MODIFY" command to any CUA.
Formal Definition: A "MODIFY" command is defined by the following
notation:
modify-cmd = modifyparam ":" "MODIFY"
;
modifyparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
Royer, et al. Experimental [Page 105]
RFC 4324 Calendar Access Protocol December 2005
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
The "MODIFY" command is used to modify existing components. The
TARGET property specifies the calendars that contain the
components that are going to be modified.
The format of the request is three components inside of
"VCALENDAR" component:
BEGIN:VCALENDAR
BEGIN:VQUERY
END:VQUERY
BEGIN:XXX
END:XXX
BEGIN:XXX
END:XXX
END:VCALENDAR
The "VQUERY" component selects the components that are to be
modified.
The "XXX" above is a named component type (VEVENT, VTODO, ...).
Both the old and new components MUST be of the same type.
The old-values is a component and the contents of that component
are going to change and may contain information that helps
uniquely identify the original component (SEQUENCE in the example
below). If the CS cannot find a component that matches the QUERY
and does not have at least all of the OLD-VALUES, then a 6.1 error
is returned.
Royer, et al. Experimental [Page 106]
RFC 4324 Calendar Access Protocol December 2005
The new-values is a component of the same type as old-values and
new-values contains the new data for each selected component. Any
data that is in old-values and not in new-values is deleted from
the selected component. Any values in new-values that was not in
old-values is added to the component.
In this example, the "VEVENT" component with a "UID" property
value of 'unique-58' has the "LOCATION" property and "LAST-
MODIFIED" properties changed, the "VALARM" component with the
"SEQUENCE" property with a value of "3" has its "TRIGGER" property
disabled, the "X-LOCAL" property is removed from the "VEVENT"
component, and a "COMMENT" property is added.
Because "SEQUENCE" property is used to locate the "VALARM"
component in this example, both the old-values and the new-values
contain the "SEQUENCE" property with a value of "3". If the
"SEQUENCE" property were to be left out of new-values, it would
have been deleted.
Example:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: TARGET:my-cal
C: CMD:ID=unique-mod:MODIFY
C: BEGIN:VQUERY <- Query to select data set.
C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58'
C: END:VQUERY
C: BEGIN:VEVENT <- Start of old data.
C: LOCATION:building 3
C: LAST-MODIFIED:20020101T123456Z
C: X-LOCAL:some private stuff
C: BEGIN:VALARM
C: SEQUENCE:3
C: TRIGGER;RELATED=END:PT5M
C: END:VALARM
C: END:VEVENT <- End of old data.
C: BEGIN:VEVENT <- Start of new data.
C: LOCATION:building 4
C: LAST-MODIFIED:20020202T010203Z
C: COMMENT:Ignore global trigger.
C: BEGIN:VALARM
C: SEQUENCE:3
C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M
C: END:VALARM
Royer, et al. Experimental [Page 107]
RFC 4324 Calendar Access Protocol December 2005
C: END:VEVENT <- End of new data.
C: END:VCALENDAR
The "X-LOCAL" property was not supplied in the new-values, so it
was deleted. The "LOCATION" property value was altered, as was
the "LAST-MODIFIED" value. The "VALARM" component with a
"SEQUENCE" property value of "3" had its "TRIGGER" property
disabled, and the "SEQUENCE" property value did not change so it
was not effected. The "COMMENT" property was added.
When it comes to inline ATTACHMENTs, the CUA only needs to
uniquely identify the contents of the ATTACHMENT value in the
old-values in order to delete them. When the CS compares the
attachment data, it is compared in its binary form. The
ATTACHMENT value supplied by the CUA MUST be valid encoded
information.
For example, to delete the same huge inline attachment from every
VEVENT in 'my-cal' that has an "ATTACH" property value with the
old-values:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//someone's prodid
TARGET:my-cal
CMD:MODIFY
BEGIN:VQUERY
QUERY:SELECT ATTACH FROM VEVENT
END:VQUERY
BEGIN:VEVENT
ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
MIICajCCAdOgAwIBAgICbeUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
...< remainder of attachment data NOT supplied >....
END:VEVENT
BEGIN:VEVENT
END:VEVENT
END:VCALENDAR
Here the new-values is empty, so everything in the old-values is
deleted.
Furthermore, the following additional restrictions apply:
1. One cannot change the "UID" property of a component.
Royer, et al. Experimental [Page 108]
RFC 4324 Calendar Access Protocol December 2005
2. If a contained component is changed inside of a selected
component, and that contained component has multiple instances,
then old-values MUST contain information that uniquely
identifies the instance or instances that are changing. It is
valid to change more than one. All contained components that
match old-values will be modified. In the first modify example
above, if "SEQUENCE" properties were to be deleted from both the
old-values and new-values, then all "TRIGGER" properties that
matched the old-values in all "VALARM" components in the
selected "VEVENT" components would be disabled.
3. The result of the modify MUST be a valid iCalendar object.
Response:
A "VCALENDAR" component is returned with one ore more "REQUEST-
STATUS" property values.
If any error occurred:
No component will be changed at all. That is, it will appear just
as it was prior to the modify and the CAP server SHOULD return a
"REQUEST-STATUS" property for each error that occurred. There
MUST be at least one error reported.
If multiple components are selected, then what uniquely identified
the component MUST be returned (UID, QUERYID, ...) if the component
contains a unique identifier. If it does not, sufficient information
to uniquely identify the modified components MUST be returned in the
reply.
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: TARGET:relcalid
S: CMD;ID=delete#1:REPLY
S: BEGIN:VREPLY
S: BEGIN:VEVENT
S: UID:123
S: REQUEST-STATUS:2.0
S: END:VEVENT
S: END:VREPLY
S: END:VCALENDAR
Royer, et al. Experimental [Page 109]
RFC 4324 Calendar Access Protocol December 2005
10.10. MOVE Command
CMD: MOVE
Purpose: The "MOVE" command is used to move components within the CS.
A CUA MAY send a "MOVE" command to a CS. The "MOVE" command MUST
be implemented by all CSs.
The CS MUST NOT send a "MOVE" command to any CUA.
Formal Definition: A "MOVE" command is defined by the following
notation:
move-cmd = moveparam ":" "MOVE"
;
moveparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
;
)
Response:
The REQUEST-STATUS in a VCALENDAR object.
The content of each "result" is subject to the result restriction
table defined below.
The access control on the "VAGENDA" component, after it has been
moved to its new location in the calstore, MUST be at least as
Royer, et al. Experimental [Page 110]
RFC 4324 Calendar Access Protocol December 2005
secure as it was prior to the move. If the CS is not able to
ensure the same level of security, a permission-denied "REQUEST-
STATUS" property value MUST be returned, and the "MOVE" command
MUST NOT be performed.
The "TARGET" property value specifies the new location, and the
"VQUERY" component specifies the old location.
Restriction Table for the "REPLY" command of any "MOVE" command.
move-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops
1*(move-vreply)
"END" ":" "VCALENDAR" CRLF
move-vreply = "BEGIN" ":" "VREPLY" CRLF
move-id
rstatus
"END" ":" "VREPLY" CRLF
; Where the id is appropriate for the
; type of object moved:
;
; VAGENDA = relcalid
; VCAR = carid
; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
; VQUERY = queryid
; ALARM = sequence
; An instance = uid recurid
; x-comp = x-id
;
move-id = ( relcalid / carid / uid / uid recurid
/ queryid / tzid / sequence / x-id)
Example: moving the VAGENDA Nellis to Area-51
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD:MOVE
C: TARGET:Area-51
C: BEGIN:VQUERY
C: QUERY: SELECT *.* FROM VAGENDA WHERE CALID='Nellis'
C: END:VQUERY
C: END:VCALENDAR
Royer, et al. Experimental [Page 111]
RFC 4324 Calendar Access Protocol December 2005
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: TARGET:Area-51
S: BEGIN:VREPLY
S: CALID:Nellis
S: REQUEST-STATUS: 2.0
S: END:VREPLY
S: END:VCALENDAR
10.11. REPLY Response to a Command
CMD: REPLY
Purpose: The "REPLY" value to the "CMD" property is used to return
the results of all other commands to the CUA.
A CUA MUST send a "REPLY" command to a CS for any command a CS MAY
send to the CUA. The "REPLY" command MUST be implemented by all
CUAs that support getting the "GET-CAPABILITY" command.
A CS MUST send a "REPLY" command to a CUA for any command a CUA
MAY send to the CS. The "REPLY" command MUST be implemented by
all CSs.
Formal Definition: A "REPLY" command is defined by the following
notation:
reply-cmd = replyparam ":" "REPLY"
;
replyparam = *(
;
; The 'id' parameter value MUST be exactly the
; same as the value sent in the original
; CMD property. If the original CMD did
; not have an 'id' parameter, then the 'id'
; MUST NOT be supplied in the REPLY.
;
id-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
Royer, et al. Experimental [Page 112]
RFC 4324 Calendar Access Protocol December 2005
10.12. SEARCH Command
CMD: SEARCH
Purpose: The "SEARCH" command is used to return selected components
to the CUA.
A CUA MAY send a "SEARCH" command to a CS. The "SEARCH" command
MUST be implemented by all CSs.
The CS MUST NOT send a "SEARCH" command to any CUA.
Formal Definition: A "SEARCH" command is defined by the following
notation:
search-cmd = searchparam ":" "SEARCH"
;
searchparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
The format of the request is the search command (search-cmd)
followed by one or more (query) "VQUERY" components
Response:
The data in each result set contains one or more iCalendar
components composed of all the selected results enclosed in a
single "VREPLY" component per "QUERY".
Royer, et al. Experimental [Page 113]
RFC 4324 Calendar Access Protocol December 2005
Only "REQUEST-STATUS" property and the properties mentioned in the
"SELECT" clause of the QUERY are included in the components. Each
"VCALENDAR" component is tagged with the "TARGET" property.
Searching for objects
In the example below, objects on March 10,1999 between 080000Z and
190000Z are read. In this case only four properties for each
object are returned. Two calendars are specified. Only booked
(vs. scheduled) entries are to be returned (this example only
selected VEVENT objects are to be returned):
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: A05 OK done
6: The following example requests the server to include mailboxes
that reside on another server. The server is asked to return
subscription information for all returned mailboxes. This is
different from the example above.
Note that the output of this command is not a superset of the
output in the previous example, as it doesn't include LIST
response for the non-existent "Fruit/Peach".
C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: * LIST (\Remote) "/" "Meat"
S: A06 OK done
7: The following example demonstrates the difference between the
\HasChildren attribute and the CHILDINFO extended data item.
Let's assume there is the following hierarchy:
C: C01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Foo"
S: * LIST () "/" "Foo/Bar"
S: * LIST () "/" "Foo/Baz"
S: * LIST () "/" "Moo"
S: C01 OK done
If the client asks RETURN (CHILDREN), it will get this:
Melnikov & Leiba Expires January 30, 2021 [Page 57]
Internet-Draft IMAP4rev2 July 2020
C: CA3 LIST "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Foo"
S: * LIST (\HasNoChildren) "/" "Moo"
S: CA3 OK done
A) Let's also assume that the mailbox "Foo/Baz" is the only
subscribed mailbox. Then we get this result:
C: C02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "Foo/Baz"
S: C02 OK done
Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
will return no mailboxes (as the mailboxes "Moo", "Foo", and
"Inbox" are NOT subscribed). However, if the client issues
this:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
(i.e., the mailbox "Foo" is not subscribed, but it has a child
that is.)
A1) If the mailbox "Foo" had also been subscribed, the last
command would return this:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
or even this:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) 's prodid
C: CMD:SEARCH
C: TARGET:relcal2
C: TARGET:relcal3
C: BEGIN:VQUERY
C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
C: FROM VEVENT
C: WHERE DTEND >= '19990310T080000Z'
C: AND DTSTART <= '19990310T190000Z'
C: AND STATE() = 'BOOKED'
C: END:VQUERY
C: END:VCALENDAR
The return values are subject to VCAR filtering. That is, if the
request contains properties to which the UPN does not have access,
those properties will not appear in the return values. If the UPN
has access to at least one property of the component, but has been
denied access to all properties called out in the request, the
response will contain a single "REQUEST-STATUS" property
indicating the error.
Here the request was successful, however one of the "VEVENT"
components contents were not accessible (4.1).
Royer, et al. Experimental [Page 114]
RFC 4324 Calendar Access Protocol December 2005
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: TARGET:relcalid
S: CMD:REPLY
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: BEGIN:VREPLY
S: BEGIN:VEVENT
S: REQUEST-STATUS:4.1
S: END:VEVENT
S: BEGIN:VEVENT
S: REQUEST-STATUS:2.0
S: UID:123
S: DTEND:19990310T080000Z
S: DSTART:19990310T190000Z
S: SUMMARY: Big meeting
S: END:VEVENT
S: END:VREPLY
S: END:VCALENDAR
If the UPN has no access to any components at all, the response
will simply be an empty data set. The response will look the same
if the particular components do not exist.
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD:REPLY
S: TARGET:ralcalid
S: BEGIN:VREPLY
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
If there are multiple targets, each iCalendar reply is contained
within its own iCalendar object.
10.12.1. Searching for VFREEBUSY
If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the
"VFREEBUSY" component in the "COMPONENTS" value in a reply to the
"GET-CAPABILITY" command, then it is the CS's responsibility (and not
the CUA's responsibility) to provide the correct "VFREEBUSY"
information for a calendar.
Royer, et al. Experimental [Page 115]
RFC 4324 Calendar Access Protocol December 2005
If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return success
and not store the "VFREEBUSY" component as the results would never be
used.
Such a CS MUST dynamically create the results of a search for
"VFREEBUSY" components at search time when searching for STATE() =
'BOOKED' items.
If a CUA searches for "VFREEBUSY" components with STATE() =
'UNPROCESSED', such a CS MUST return a "VREPLY" with no components.
If a CUA searches for "VFREEBUSY" components without specifying the
STATE, such a CS MUST return the same result as if STATE()='BOOKED'
had been specified.
For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE"
and have the "VFREEBUSY" component in the "COMPONENTS" value in the
"CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on
the CS. These CSs then MUST return a "VFREEBUSY" component
calculated from the stored components. If no "VFREEBUSY" information
is available for the "TARGET" calendar, then a "VFREEBUSY" with no
blocked out time will be returned with a success code. A CUA sets
the "VFREEBUSY" time on a/those calendars by creating a "VFREEBUSY"
component without a "" "%"
S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO"
("SUBSCRIBED"))
S: C04 OK done
A2) If we assume instead that the mailbox "Foo" is not part of
the original hierarchy and is not subscribed, the last command
will give this result:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
Melnikov & Leiba Expires January 30, 2021 [Page 58]
Internet-Draft IMAP4rev2 July 2020
B) Now, let's assume that no mailbox is subscribed. In this
case, the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will
return no responses, as there are no subscribed children (even
though "Foo" has children).
C) And finally, suppose that only the mailboxes "Foo" and "Moo"
are subscribed. In that case, we see this result:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done
(which means that the mailbox "Foo" has children, but none of
them is subscribed).
8: The following example demonstrates that the CHILDINFO extended
data item is returned whether or not children mailboxes match
the canonical LIST pattern.
Let's assume there is the following hierarchy:
C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2"
S: * LIST () "/" "baz2"
S: * LIST () "/" "baz2/bar2"
S: * LIST () "/" "baz2/bar22"
S: * LIST () "/" "baz2/bar222"
S: * LIST () "/" "eps2"
S: * LIST () "/" "eps2/mamba"
S: * LIST () "/" "qux2/bar2"
S: D01 OK done
And that the following mailboxes are subscribed:
C: D02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2"
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D02 OK done
Melnikov & Leiba Expires January 30, 2021 [Page 59]
Internet-Draft IMAP4rev2 July 2020
The client issues the following command first:
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
S: * LIST () "/" "foo2quot;METHOD" creating a "BOOKED" entry.
If a CS does not set the "VFREEBUSY" value in the "COMPONENTS"
"CAPABILITY" value, the CS does not support the "VFREEBUSY" component
and all creation and searching for a "VFREEBUSY" component MUST fail.
Examples of calendars that may be in this category are public event
calendars that will never require scheduling with other UPNs.
10.13. SET-LOCALE Command
CMD: SET-LOCALE
Purpose: The "SET-LOCALE" command is used to select the locale that
will be used in error codes that are used in the "REQUEST-STATUS"
property.
A CUA MAY send a "SET-LOCALE" command to a CS. The SET-LOCALE
command MUST be implemented by all CSs.
The CS MUST NOT send a "SET-LOCALE" command to any CUA.
Formal Definition: A "SET-LOCALE" command is defined by the following
notation:
setlocale-cmd = setlocaleparam ":" "SET-LOCALE"
Royer, et al. Experimental [Page 116]
RFC 4324 Calendar Access Protocol December 2005
;
setlocaleparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
/ setlocale-option
;
; the following MUST occur exactly once and only
; only when the latency-param has been supplied.
; It MUST NOT be supplied if the latency-param
; is not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params )
setlocale-option = option-param newlocale
;
newlocale = ; Any locale supplied in the initial [BEEP]
; "greeting" "localize" parameter and
; and any charset supported by the CS
; and listed in the DEFAULT-CHARSET property
; of the VCALSTORE
Examples:
CMD:OPTIONS=en_US.UTF-8:SET-LOCALE
CMD:OPTIONS=th_TH.ISO8859-11:SET-LOCALE
CMD:OPTIONS=es_MX.ISO8859-1:SET-LOCALE
Restriction Table for the "REPLY" command of any "SET-LOCALE"
command.
setlocale-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops
1*(setlocale-vreply)
"END" ":" "VCALENDAR" CRLF
setlocale-vreply = "BEGIN" ":" "VREPLY" CRLF
rstatus
"END" ":" "VREPLY" CRLF
Royer, et al. Experimental [Page 117]
RFC 4324 Calendar Access Protocol December 2005
10.14. TIMEOUT Command
CMD: TIMEOUT
Purpose: The "TIMEOUT" command is only sent after a command has been
sent with a latency value set. When received, it means the
command could not be completed in the time allowed.
Formal Definition: A "TIMEOUT" command is defined by the following
notation:
timeout-cmd = timeoutparam ":" "TIMEOUT"
timeoutparam = *(
; the following are optional,
; but MUST NOT occur more than once
id-param
/ localize-param
/ other-params
)
10.15. Response Codes
Numeric response codes are returned using the "REQUEST-STATUS"
property.
The format of these codes is described in [iCAL] and extended in
[iTIP] and [iMIP]. The following describes new codes added to this
set and how existing codes apply to CAP.
At the application layer, response codes are returned as the value of
a "REQUEST-STATUS" property. The value type of this property is
modified from that defined in [iCAL], in order to make the
accompanying "REQUEST-STATUS" property text optional.
Code Description
--------------------------------------------------------------
2.0 Success. The parameters vary with the
operation and are specified.
2.0.3 In response to the client issuing an
"abort" reply, this reply code indicates
that any command currently underway was
successfully aborted.
3.1.4 Capability not supported.
4.1 Calendar store access denied.
Royer, et al. Experimental [Page 118]
RFC 4324 Calendar Access Protocol December 2005
6.1 Container not found.
6.2 Attempt to create or modify an object
that would overlap another object
in either of the following two circumstances:
(a) One of the objects has a TRANSP
property set to OPAQUE-NOCONFLICT or
TRANSPARENT-NOCONFLICT.
(b) The calendar's ALLOW-CONFLICT
property is set to FALSE.
6.3 Bad args.
6.4 Permission denied - VCAR restriction.
A VCAR exists and the CS will not perform
the operation.
7.0 A timeout has occurred. The server was
unable to complete the operation in the
requested time.
8.0 A failure has occurred in the CS
that prevents the operation from
succeeding.
8.1 A query was performed and the query is
too complex for the CS. The operation
was not performed.
8.2 Used to signal that an iCalendar object has
exceeded the server's size limit
8.3 A DATETIME value was too far in the future
to be represented on this Calendar.
8.4 A DATETIME value was too far in the past
to be represented on this Calendar.
8.5 An attempt was made to create a new
object, but the unique UID specified is
already in use.
9.0 An unrecognized command was received.
Or an unsupported command was received.
Royer, et al. Experimental [Page 119]
RFC 4324 Calendar Access Protocol December 2005
10.4 The operation has not been performed
because it would cause the resources
(memory, disk, CPU, etc) to exceed the
allocated quota.
--------------------------------------------------------------
11. Object Registration
This section provides the process for registration of new or modified
properties, parameters, commands, or other modifications, additions,
or deletions to objects.
11.1. Registration of New and Modified Entities
New objects are registered by the publication of an IETF Request for
Comment (RFC). Changes to objects are registered by the publication
of a revision to the RFC in a new RFC.
11.2. Post the Item Definition
The object description MUST be posted to the new object discussion
list: ietf-calendar@imc.org.
11.3. Allow a Comment Period
Discussion on a new object MUST be allowed to take place on the list
for a minimum of two weeks. Consensus MUST be reached on the object
before proceeding to the next step.
11.4. Release a New RFC
The new object will be submitted for publication like any other
Internet Draft requesting RFC status.
12. BEEP and CAP
12.1. BEEP Profile Registration
BEEP replies will be one-to-one (1:1 MSG/RPY) if possible, and one-
to-many (1:many MSG/ANS) when the "TARGET" property value changes.
No more than one "TARGET" property value is allowed per reply.
Profile Identification: specify a [URI] that authoritatively
identifies this profile.
http://iana.org/beep/cap/1.0
Message Exchanged during Channel Creation:
Royer, et al. Experimental [Page 120]
RFC 4324 Calendar Access Protocol December 2005
CUAs SHOULD supply the BEEP "localize" attributes in the BEEP
"greeting" messages.
CSs SHOULD supply the BEEP "localize" attributes in the BEEP
"greeting" messages.
CUAs SHOULD supply the BEEP "serverName" attribute at channel
creation time to the CS, so that, if the CS is performing virtual
hosting, the CS can determine the intended virtual host. CSs that
do not support virtual hosting may ignore the BEEP "serverName"
attribute.
Messages starting one-to-one exchanges:
The initial message, after authentication in each direction, MUST
be a single "text/calendar" object containing a CAP "CAPABILITY"
CMD. It must not be part of a MIME multipart message.
After the initial message, a BEEP "MSG" may contain one or more
MIME objects (at least one of which MUST be "text/calendar"), and
each "text/calendar" MIME object MUST contain a CAP "CMD"
property.
Multiple iCalendar objects may be sent in a single BEEP message
either by representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
In either case, all iCalendar objects that are transmitted
together must have the same TARGET property.
The sending of multipart MIME entities over BEEP is not permitted
for CAP unless the other endpoint has indicated its ability to
accept them via the appropriate CAPABILITY.
Messages in positive replies:
After the initial message, a BEEP "RPY" may contain one or more
MIME objects (at least one of which MUST be "text/calendar"), and
each "text/calendar" MIME object MUST contain a CAP "CMD"
property. All "text/calendar" MIME objects in a single BEEP "RPY"
messages MUST have the same "TARGET" property value.
Multiple iCalendar objects may be sent in a single BEEP message by
either representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
Royer, et al. Experimental [Page 121]
RFC 4324 Calendar Access Protocol December 2005
In either case, all iCalendar objects transmitted together must
have the same TARGET property.
Sending multipart MIME entities over BEEP is not permitted for CAP
unless the other endpoint has indicated its ability to accept them
via the appropriate CAPABILITY.
Messages in negative replies:
Will contain any valid "text/calendar" MIME object that contains
CAP "REQUEST-STATUS" property and a CAP "CMD" property with a
property value of "REPLY". And where the CS has determined the
requested operation to be a fatal error. And when the CS has
performed NO operation that effected the contents of any part of
the CS or any calendar controlled by the CS.
Messages in one-to-many exchanges:
After the initial message then a BEEP "MSG" may contain one or
more MIME objects at least one of which MUST be "text/calendar"
and each "text/calendar" MIME object MUST contain a CAP "CMD"
property.
The BEEP "MSG" messages can only contain MIME "multipart" MIME
objects if the other endpoint has received a CAP "CAPABILITY"
indicating the other endpoint supports multipart MIME objects.
This does not prevent the endpoint from sending multiple [iCAL]
'icalobject' objects in a single BEEP "MSG" so long as all of them
have the same "TARGET" property value.
Multiple iCalendar objects may be sent in a single BEEP message by
either representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
In either case, all iCalendar objects transmitted together must
have the same TARGET property.
The sending of multipart MIME entities over BEEP is not permitted
for CAP unless the other endpoint has indicated its ability to
accept them via the appropriate CAPABILITY.
Message Syntax:
They are CAP "text/calendar" MIME objects as specified in this
memo.
Royer, et al. Experimental [Page 122]
RFC 4324 Calendar Access Protocol December 2005
Message Semantics:
As defined in this memo.
12.2. BEEP Exchange Styles
[BEEP] defines three styles of message exchange:
MSG/ANS,ANS,...,NUL - For one to many exchanges.
MSG/RPY - For one to one exchanges.
MSG/ERR - For requests the cannot be processed due to an error.
A CAP request targeted at more than one container MAY use a one- to-
many exchange with a distinct answer associated with each target. A
CAP request targeted at a single container MAY use a one-to-one
exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when
an error condition prevents the execution of the request on all the
targeted calendars.
12.3. BEEP Connection Details
All CAP communications must be done securely, so the initial greeting
includes the TLS profile.
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting/>
I: END
At this point, the connection is secure. The TLS profile 'resets'
the connection, so it resends the greetings, advertises the CAP
profiles that are supported, and replies with the profile selected
(only one profile exists at this time):
Royer, et al. Experimental [Page 123]
RFC 4324 Calendar Access Protocol December 2005
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/cap/1.0'/>
L: </greeting>
L: END
I: RPY 0 0 . 0 110
I: Content-Type: application/beep+xml
I:
I: <greeting>
I: <profile uri='http://iana.org/beep/cap/1.0'/>
I: </greeting>
I: END
Each channel must be authenticated before work can start, but
starting a channel involves authentication. Any SASL profile may be
included, for example:
<profile uri='http://iana.org/beep/SASL/OTP'/>
<profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
<profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
Example of anonymous channel:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
C: </start>
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
S: END
Example of DIGEST-MD5 channel:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
C: </start>
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
Royer, et al. Experimental [Page 124]
RFC 4324 Calendar Access Protocol December 2005
S:
S: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
S: END
Piggybacking the "CAPABILITY" command.
The "CAPABILITY" reply may be included during channel start (see
RFC3080, section 2.3.1.2), as BEEP allows the start command to
include the initial data transfer. This reduces the number of round
trips to initiate a CAP session.
13. IANA Considerations
This memo defines IANA-registered extensions to the attributes
defined by iCalendar, as defined in [iCAL], and [iTIP].
IANA registration proposals for iCalendar and [iTIP] are to be mailed
to the registration agent for the "text/calendar" [MIME] content-
type, <MAILTO: ietf-calendar@imc.org> using the format defined in
section 7 of [iCAL].
The the IANA has registered the profile specified in Section 12.1,
and has selected an IANA-specific URI: http://iana.org/beep/cap/1.0.
14. Security Considerations
Access rights should be granted cautiously. Without careful
planning, it is possible to open up access to a greater degree than
desired.
The "IDENTIFY" command should be carefully implemented. If it is
done incorrectly, UPNs may gain access as other, unintended, UPNs.
The "IDENTIFY" command may not chain; that is, the identity is always
validated against the original UPN and not the new UPN.
Since CAP is a profile of [BEEP], consult [BEEP]'s Section 9 for a
discussion of BEEP-specific security issues.
There are risks of allowing anonymous UPNs to deposit REQUEST and
REFRESH objects (calendar spam and denial-of-service, for example).
Implementations should consider methods to restrict anonymous
requests to within acceptable usages.
CS implementations might consider automatically creating VCARs that
allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY
objects for those UIDs if they otherwise do not have access rather
then opening up world access. And they may also consider allowing
COUNTER objects for those ATTENDEEs.
Royer, et al. Experimental [Page 125]
RFC 4324 Calendar Access Protocol December 2005
When an object is booked by a CUA ,the CS reply may wish to include
warning messages to the CUA for ATTENDEEs that have CAP urls that do
not have local UPNs as those ATTENDEES may be unable to REPLY or
REFRESH. Some CSs may wish this to be an error.
Although service provisioning is a policy matter, at a minimum, all
implementations must provide the following tuning profiles:
o for authentication: http://iana.org/beep/SASL/DIGEST-MD5
o for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
o for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates)
Royer, et al. Experimental [Page 126]
RFC 4324 Calendar Access Protocol December 2005
Appendix A. Acknowledgements
The following individuals were major contributors to the drafting and
discussion of this memo, and they are greatly appreciated:
Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil
Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag,
Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan,
Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt
Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan
Kohn, Dan Winship, Darryl Champagne, David C. Thewlis, David Nicol,
David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank
Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin,
Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand,
Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray,
Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke,
Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees
Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence
Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark
Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle,
Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max
Froumentin, Micah Gorrell, Michael Fair, Mike Higginbottom, Mike
Hixson, Murata Makoto, Natalia Syracuse, Nathaniel Borenstein, Ned
Freed, Olivier Gutknecht, Patrice Lapierre, Patrice Scattolin, Paul
Hoffman, Paul Sharpe, Payod Deshpande, Pekka Pessi, Peter Thompson,
Preston Stephenson, Prometeo Sandino Roman Corral, Ralph Patterson,
Robert Lusardi, Robert Ransdell, Rob Siemborski, Satyanarayana
Vempati, Satya Vempati, Scott Hollenbeck, Seamus Garvey, Shannon
Clark, Shriram Vishwanathan, Steve Coya, Steve Mansour, Steve Miller,
Steve Vinter, Stuart Guthrie, Suchet Singh Khalsa, Ted Hardie, Tim
Hare, Timo Sirainen, Vicky Oliver, Paul Hill, and Yael Shaham-Gafni.
Appendix B. References
Appendix B.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081,
March 2001.
[BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596-
00244-0, O'Reilly & Associates, Inc.
Royer, et al. Experimental [Page 127]
RFC 4324 Calendar Access Protocol December 2005
[GUIDE] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet
Calendaring", RFC 3283, June 2002.
[iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC
2445, November 1998.
[iTIP] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson,
"iCalendar Transport-Independent Interoperability
Protocol (iTIP) Scheduling Events, BusyTime, To-dos and
Journal Entries", RFC 2446, November 1998.
[iMIP] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
Message-Based Interoperability Protocol (iMIP)", RFC
2447, November 1998.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
Appendix B.2. Informative References
" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done
and the server may also include (but this would violate a SHOULD
NOT in Section 3.5, because CHILDINFO is redundant)
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
The CHILDINFO extended data item is returned for mailboxes
"foo2", "baz2", and "eps2", because all of them have subscribed
children, even though for the mailbox "foo2" only one of the two
subscribed children matches the pattern, for the mailbox "baz2"
all the subscribed children match the pattern, and for the
mailbox "eps2" none of the subscribed children matches the
pattern.
Note that if the client issues
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done
The LIST responses for mailboxes "foo2", "baz2", and "eps2"
still have the CHILDINFO extended data item, even though this
information is redundant and the client can determine it by
itself.
9: The following example shows usage of extended syntax for mailbox
pattern. It also demonstrates that the presence of the
Melnikov & Leiba Expires January 30, 2021 [Page 60]
Internet-Draft IMAP4rev2 July 2020
CHILDINFO extended data item doesn't necessarily imply
\HasChildren.
C: a1 LIST "" ("foo")
S: * LIST () "/" foo
S: a1 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: a3 OK done
10: The following example shows how a server that supports missing
mailbox hierarchy elements can signal to a client that didn't
specify the RECURSIVEMATCH selection option that there is a
child mailbox that matches the selection criteria.
C: a1 LIST (REMOTE) "" *
S: * LIST () "/" music/rock
S: * LIST (\Remote) "/" also/jazz
S: a1 OK done
C: a2 LIST () "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: a2 OK done
C: a3 LIST (REMOTE) "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: * LIST (\NonExistent \HasChildren) "/" also
S: a3 OK done
C: a3.1 LIST "" (% music/rock)
S: * LIST () "/" music/rock
S: a3.1 OK done
Because "music/rock" is the only mailbox under "music", there's
no need for the server to also return "music". However clients
must handle both cases.
11: The following examples show use of STATUS return option.
Melnikov & Leiba Expires January 30, 2021 [Page 61]
Internet-Draft IMAP4rev2 July 2020
C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
S: * LIST () "." "INBOX"
S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
S: * LIST () "." "foo"
S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
S: * LIST (\NoSelect) "." "bar"
S: A01 OK List completed.
The "bar" mailbox isn't selectable, so it has no STATUS reply.
C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % RETURN (STATUS
(MESSAGES))
S: * LIST (\Subscribed) "." "INBOX"
S: * STATUS "INBOX" (MESSAGES 17)
S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
S: A02 OK List completed.
The LIST reply for "foo" is returned because it has matching
children, but no STATUS reply is returned because "foo" itself
doesn't match the selection criteria.
6.3.10. NAMESPACE Command
Arguments: none
Responses: REQUIRED untagged responses: NAMESPACE
Result: OK - command completed
NO - Can't complete the command
BAD - arguments invalid
The NAMESPACE command causes a single ungagged NAMESPACE response to
be returned. The untagged NAMESPACE response contains the prefix and
hierarchy delimiter to the server's Personal Namespace(s), Other
Users' Namespace(s), and Shared Namespace(s) that the server wishes
to expose. The response will contain a NIL for any namespace class
that is not available. The Namespace-Response-Extensions ABNF non
terminal is defined for extensibility and MAY be included in the
NAMESPACE response.
Example 1:
In this example a server supports a single personal namespace. No
leading prefix is used on personal mailboxes and "/" is the hierarchy
delimiter.
Melnikov & Leiba Expires January 30, 2021 [Page 62]
Internet-Draft IMAP4rev2 July 2020
C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) NIL NIL
S: A001 OK NAMESPACE command completed
Example 2:
A user logged on anonymously to a server. No personal mailboxes are
associated with the anonymous user and the user does not have access
to the Other Users' Namespace. No prefix is required to access
shared mailboxes and the hierarchy delimiter is "."
C: A001 NAMESPACE
S: * NAMESPACE NIL NIL (("" "."))
S: A001 OK NAMESPACE command completed
Example 3:
A server that contains a Personal Namespace and a single Shared
Namespace.
C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
S: A001 OK NAMESPACE command completed
Example 4:
A server that contains a Personal Namespace, Other Users' Namespace
and multiple Shared Namespaces. Note that the hierarchy delimiter
used within each namespace can be different.
C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
("#public/" "/")("#ftp/" "/")("#news." "."))
S: A001 OK NAMESPACE command completed
The prefix string allows a client to do things such as automatically
creating personal mailboxes or LISTing all available mailboxes within
a namespace.
Example 5:
A server that supports only the Personal Namespace, with a leading
prefix of INBOX to personal mailboxes and a hierarchy delimiter of
"."
Melnikov & Leiba Expires January 30, 2021 [Page 63]
Internet-Draft IMAP4rev2 July 2020
C: A001 NAMESPACE
S: * NAMESPACE (("INBOX." ".")) NIL NIL
S: A001 OK NAMESPACE command completed
< Automatically create a mailbox to store sent items.>
C: A002 CREATE "INBOX.Sent Mail"
S: A002 OK CREATE command completed
Although typically a server will support only a single Personal
Namespace, and a single Other User's Namespace, circumstances exist
where there MAY be multiples of these, and a client MUST be prepared
for them. If a client is configured such that it is required to
create a certain mailbox, there can be circumstances where it is
unclear which Personal Namespaces it should create the mailbox in.
In these situations a client SHOULD let the user select which
namespaces to create the mailbox in or just use the first personal
namespace.
Example 6:
In this example, a server supports 2 Personal Namespaces. In
addition to the regular Personal Namespace, the user has an
additional personal namespace to allow access to mailboxes in an MH
format mailstore.
The client is configured to save a copy of all mail sent by the user
into a mailbox called 'Sent Mail'. Furthermore, after a message is
deleted from a mailbox, the client is configured to move that message
to a mailbox called 'Deleted Items'.
Note that this example demonstrates how some extension flags can be
passed to further describe the #mh namespace.
Melnikov & Leiba Expires January 30, 2021 [Page 64]
Internet-Draft IMAP4rev2 July 2020
C: A001 NAMESPACE
S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
("FLAG1" "FLAG2"))) NIL NIL
S: A001 OK NAMESPACE command completed
< It is desired to keep only one copy of sent mail.
It is unclear which Personal Namespace the client
should use to create the 'Sent Mail' mailbox.
The user is prompted to select a namespace and only
one 'Sent Mail' mailbox is created. >
C: A002 CREATE "Sent Mail"
S: A002 OK CREATE command completed
< The client is designed so that it keeps two
'Deleted Items' mailboxes, one for each namespace. >
C: A003 CREATE "Delete Items"
S: A003 OK CREATE command completed
C: A004 CREATE "#mh/Deleted Items"
S: A004 OK CREATE command completed
The next level of hierarchy following the Other Users' Namespace
prefix SHOULD consist of <username>, where <username> is a user name
as per the LOGIN or AUTHENTICATE command.
A client can construct a LIST command by appending a "%" to the Other
Users' Namespace prefix to discover the Personal Namespaces of other
users that are available to the currently authenticated user.
In response to such a LIST command, a server SHOULD NOT return user
names that have not granted access to their personal mailboxes to the
user in question.
A server MAY return a LIST response containing only the names of
users that have explicitly granted access to the user in question.
Alternatively, a server MAY return NO to such a LIST command,
requiring that a user name be included with the Other Users'
Namespace prefix before listing any other user's mailboxes.
Example 7:
A server that supports providing a list of other user's mailboxes
that are accessible to the currently logged on user.
Melnikov & Leiba Expires January 30, 2021 [Page 65]
Internet-Draft IMAP4rev2 July 2020
C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
S: A001 OK NAMESPACE command completed
C: A002 LIST "" "Other Users/%"
S: * LIST () "/" "Other Users/Mike"
S: * LIST () "/" "Other Users/Karen"
S: * LIST () "/" "Other Users/Matthew"
S: * LIST () "/" "Other Users/Tesa"
S: A002 OK LIST command completed
Example 8:
A server that does not support providing a list of other user's
mailboxes that are accessible to the currently logged on user. The
mailboxes are listable if the client includes the name of the other
user with the Other Users' Namespace prefix.
C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
S: A001 OK NAMESPACE command completed
< In this example, the currently logged on user has access to
the Personal Namespace of user Mike, but the server chose to
suppress this information in the LIST response. However,
by appending the user name Mike (received through user input)
to the Other Users' Namespace prefix, the client is able
to get a listing of the personal mailboxes of user Mike. >
C: A002 LIST "" "#Users/%"
S: A002 NO The requested item could not be found.
C: A003 LIST "" "#Users/Mike/%"
S: * LIST () "/" "#Users/Mike/INBOX"
S: * LIST () "/" "#Users/Mike/Foo"
S: A003 OK LIST command completed.
A prefix string might not contain a hierarchy delimiter, because in
some cases it is not needed as part of the prefix.
Example 9:
A server that allows access to the Other Users' Namespace by
prefixing the others' mailboxes with a '~' followed by <username>,
where <username> is a user name as per the LOGIN or AUTHENTICATE
command.
Melnikov & Leiba Expires January 30, 2021 [Page 66]
Internet-Draft IMAP4rev2 July 2020
C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) (("~" "/")) NIL
S: A001 OK NAMESPACE command completed
< List the mailboxes for user mark >
C: A002 LIST "" [CHARREG] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", RFC 2278, January 1998.
[CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and
Languages", RFC 2277, January 1998.
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka
ANSI X3.135-1992, aka FIPS PUB 127-2
[SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1
to ISO/IEC 9075: 1992, also adopted as Amendment 1 to
ANSI X3.135.1992
[URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November
1999.
Royer, et al. Experimental [Page 128]
RFC 4324 Calendar Access Protocol December 2005
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005.
[URL] Berners-Lee, T, Masinter, L., and M. McCahil, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[X509CRL] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
Royer, et al. Experimental [Page 129]
RFC 4324 Calendar Access Protocol December 2005
Authors' Addresses
Doug Royer
IntelliCal, LLC
267 Kentlands Blvd. #3041
Gaithersburg, MD 20878
US
Phone: +1-866-594-8574
Fax: +1-866-594-8574
EMail: Doug@IntelliCal.com
URI: http://Royer.com
George Babics
Oracle
600 Blvd. de Maisonneuve West
Suite 1900
Montreal, Quebec H3A 3J2
CA
Phone: +1-514-905-8694
EMail: george.babics@oracle.com
Steve Mansour
eBay
2145 Hamilton Avenue
San Jose, CA 95125
USA
Phone: +1-408-376-8817
EMail: smansour@ebay.com
Royer, et al. Experimental [Page 130]
RFC 4324 Calendar Access Protocol December 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Royer, et al. Experimental [Page 131]