Lemonade Internet Draft: P-IMAP S. H. Maes Document: draft-maes-lemonade-p-imap-06.txt C. Kuang R. Lima R. Cromwell V. Ha E. Chiu J. Day R. Ahad Oracle Corporation Wook-Hyun Jeong Samsung Electronics Co., LTD Gustaf Rosell Sony Ericsson J. Sini Symbol Technologies Sung-Mu LGE Fan Xiaohui Zhaolijun China Mobile Expires: August 2005 February 2005 Push Extensions to the IMAP Protocol (P-IMAP) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." Maes [Page 1] February 2005 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Push Extensions to the IMAP protocol (P-IMAP) defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources. The first enhancement of P-IMAP is extended support to push crucial changes actively to a client, rather then requiring the client to initiate contact to ask for state changes. In addition, P-IMAP contains extensions for email filter management, message delivery, and maintaining up-to-date personal information. Bindings to specific transport are explicitly defined. Eventually P-IMAP aims at being neutral to the network transport neutrality. Conventions used in this document 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocol(s) it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for a protocol is said to be "unconditionally compliant" to that protocol; one that satisfies all the MUST level requirements but not all the SHOULD level requirements is said to be "conditionally compliant." When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. Table of Contents Status of this Memo...............................................1 Abstract..........................................................2 Conventions used in this document.................................2 Table of Contents.................................................2 1. Introduction...................................................4 Maes Expires - August 2005 [Page 2] February 2005 1.1. The Poll Model vs. the Push Model.........................4 1.2. Synchronization Techniques................................5 1.2.1. State-Comparison-Based Synchronization...............6 1.2.2. Event-based Synchronization..........................7 1.2.3. Reconnecting in a same session.......................8 1.3. The Server-Side Filtering in P-IMAP.......................9 1.4. Extra Functionality in P-IMAP............................10 2. Relation with the Lemonade Profile and other E-mail specifications.........................11 3. The P-IMAP Design.............................................12 3.1. Implementing Filters.....................................12 3.1.1. The View Filter.....................................12 3.1.2. The Notification Filter.............................13 3.1.3. The Event Filter....................................13 3.2. Connectivity Models......................................13 3.2.1. In-Response Connectivity............................13 3.2.2. Inband Connectivity.................................14 3.2.3. Outband Connectivity..............,.................15 3.3. Recommended Connectivity Models..........................15 3.4. Keeping the Client In Sync with the Mobile Repository....16 4. Events........................................................16 4.1. Message Events Sent During Inband and Inresponse Mode....16 5. Interactions between the P-IMAP Client and P-IMAP Server......17 5.1. Revisions to IMAPv4 Rev1 Behavior........................19 5.1.1. UID.................................................19 5.1.2. Mobile Repository...................................19 5.1.3. The CAPABILITY Command..............................20 5.1.4. P-IMAP Session/Login................................20 5.1.5. IDLE................................................22 5.1.6. XENCRYPTED..........................................22 5.2. P-IMAP Extension Commands and Responses..................23 5.2.1. XPROVISION..........................................23 5.2.2. XSETPIMAPPREF & XGETPIMAPPREFS......................24 5.2.3. XFILTER.............................................28 5.2.4. XZIP................................................29 5.2.5. XDELIVER............................................29 5.2.6. XCONVERT & UID XCONVERT.............................31 5.2.7. XPSEARCH............................................33 Security Considerations..........................................34 References.......................................................34 Normative Appendices.............................................36 A. Implementation Guidelines for a P-IMAP Session.............36 A.1. HTTP/HTTPS Request/Response Format....................36 A.2. Using HTTP vs. HTTPS..................................37 A.3. Using Persistent HTTP/HTTPS for In-band Mode..........37 B. Event Payload..............................................38 B.1. Event Payload in Clear Text for P-IMAP Sessions.......38 B.2. Outband Channel Event Payload.........................38 C. Security Issues for Proxy-Based Implementations of P-IMAP..40 Maes Expires - August 2005 [Page 3] February 2005 Non-Normative Appendices.........................................41 D. Use Cases..................................................41 D.1. State Comparison-Based Sync...........................41 D.2. Event-Based Sync......................................42 E. Other Issues...............................................43 E.1. Using a Side Channel for a P-IMAP session.............43 E.2. Out-of-scope client event filtering...................43 Future Work......................................................44 Acknowledgments..................................................49 Authors Addresses................................................49 Intellectual Property Statement..................................51 Full Copyright Statement.........................................51 1. Introduction The Push-IMAP protocol (P-IMAP) is based on IMAPv4 Rev1 [RFC3501], but contains additional enhancements for optimization in a mobile setting. Thus, the client devices in this document are assumed to be mobile with limited resources. P-IMAP takes into account the limited resources of mobile devices, as well as extra functionality desired. This document covers key P-IMAP concepts, defines the syntax and functionality of the server and client, as well as provides examples of interactions within the protocol. P-IMAP can be bound to any transport protocol for inband and outband connectivity. Appendix A provides a normative binding to HTTP. The organization of this document is as follows. The rest of this section introduces the core enhancements of P-IMAP so the reader can gain an understanding of the concepts that drive this design. Section 2 positions P-IMAP and the Lemonade Pull Model described in [LEMONADEPROFILE]. Section 3 discusses actual design decisions for P-IMAP. Section 4 defines the bindings for expressing events, while Section 5 is the main body of the protocol, which describes the interactions between the P-IMAP server and client. Next are sections concerning the formal syntax, security considerations, and references. Finally, there are normative and non-normative appendices, which provide useful information for those who wish to implement the P-IMAP protocol. The normative appendices, including Appendices A, B, and C cover some extra guidelines needed to support implementation level issues. The non-normative appendices, D and E, provide interesting use cases and examples. 1.1. The Poll Model vs. the Push Model Today, most of the existing email clients implement a polling model, where the end user is notified of changes to an email account only after the email client polls the server for changes. How long it Maes Expires - August 2005 [Page 4] February 2005 takes a client to learn of a change on the server is thus dependent on how often the client polls for changes. Many clients can poll at high rates so that the client can quickly learn of changes and reflect them on the client display to achieve a quasi-real time synchronization experience for the end user. The periodic poll model is used on conventional email clients. Because the client must continuously poll the server for changes, the bandwidth requirements can be quite high and the connection quality must be good in order to provide a quasi-real time experience to the user. This also generates additional load on the IMAP server. The periodic poll model is illustrated in Figure 1. +--------------------+ Poll +--------------+ | | <------------ | | | Mail Server | | Email Client | | | ------------> | | +--------------------+ Response +--------------+ Figure 1: Periodic Poll Model Another way to achieve synchronization is for the email server to initiate a session with the client when a crucial change to an email occurs, which is the push model. When important events happen to a user's email account, the server informs the client device about the event, and then the client can respond to that event as necessary. In this case, the client device does not need to periodically poll the mail server, so the push model is particularly effective in the mobile computing environment when the cost of constant polling is high. The P-IMAP protocol defines the semantics for pushing events to a client. The push model is seen in Figure 2. Event +----------------+ Push +--------------+ --------> | Mail Server | ---------> | Email Client | +----------------+ +--------------+ Figure 2: Push Model 1.2. Synchronization Techniques After a client receives a notification that informs it that changes have occurred to a mailbox, it needs to employ a synchronization technique to reflect the server side changes onto the client device and the client device changes onto the server side. There are many techniques for determining what the changes between a server and client are. In this section, two techniques are presented that aim to keep a client device in sync with a given email account, meaning Maes Expires - August 2005 [Page 5] February 2005 that the set of messages on the client device is the same as that in the given email account. 1.2.1. State-Comparison-Based Synchronization IMAPv4Rev1 clients use a state-comparison-based synchronization technique to be in sync with an email account. This technique is used when the client device connects to the server and establishes a new session. This technique requires the client to ask the server for information regarding all the folders and all the messages in each folder stored on the server. Client changes must be applied on the server first. The client must then compute the difference between the server state and the client device state, and make all necessary changes so that the client device state matches the server state. An example of the interaction between the client and server in the IMAPv4 Rev1 protocol for performing a state-comparison-based sync follows. First, the client must retrieve the folders from the server. The client should issue LIST to figure out which folders have to be retrieved. It than uses LSUB to determine which folders are subscribed. For example: C: A002 LIST "" "%" S: * LIST (\NoInferiors) "/" "Drafts" S: * LIST () "/" "Friends" S: * LIST (\NoInferiors) "/" "INBOX" S: A003 OK completed C: A002 LSUB "" "*" S: * LSUB () "/" "Drafts" S: * LSUB () "/" "Friends" S: * LSUB () "/" "INBOX" S: A002 OK LSUB completed Note, that the client should not use LIST "" *, as it might cause too much data to be returned. The client must compare its folders with the responses of the command above. If it does not have a folder, it must create that folder on the client device. If there is a folder on the device that is not in any of these responses, then the client must delete that folder. In order to avoid loosing changes performed on the client, the client should apply its changes first. In case when the client has changes to a folder that was deleted on the server, it should ask the user whether the changes should be uploaded to a different mailbox or be discarded (or be configured to automatically do one of the two). Next, the client needs to make sure that the emails in each of its folders match the server. It performs a SELECT and then a FETCH Maes Expires - August 2005 [Page 6] February 2005 command for each folder. A sample of a SELECT and FETCH command for the inbox is as follows: C: A003 SELECT "INBOX" S: * 60 EXISTS S: ... more untagged responses with information about the folder S: A003 OK SELECT completed C: A004 FETCH 1:* (FLAGS UID) S: * 1 FETCH (FLAGS (\Answered) UID 120) S: * 2 FETCH (FLAGS (\Seen) UID 121) S: ... flags for messages with message sequence numbers 3-59 S: * 60 FETCH (FLAGS () UID 250) S: A004 OK FETCH completed The client must go through the full list of email messages in each folder. It must add an email in this list if it is not already on the client. It must modify any email in this list on the client device to reflect any changes to the mutable flags of that message using IMAP STORE command. Also, it should remove any emails on the client device not in this list. After performing these operations, the client is in sync with the server. 1.2.2. Event-based Synchronization Another technique is event-based synchronization. Event-based synchronization is used to keep the client device in sync with the server. This method requires that the client has been fully synchronized with the server at some earlier point. In the IMAPv4Rev1 protocol, the client must perform a state-comparison-based sync when it selects a folder, but then it can use event-based synchronization to keep itself in sync after that. Although event- based synchronization cannot totally replace state-comparison-based synchronization, it is a faster alternative for the client to maintain synchrony when the server is capable of change tracking for a client. In event-based synchronization, the server keeps track of what changes have occurred to the email account that are not yet reflected on the client device. Such a change is called an event. When the client finishes processing all events since the last time it was in sync with the server, it is again in sync with the server. Event- based synchronization is particularly effective when the server can push events to the client for immediate processing. In this case, there are likely to be only a small number of events the client needs to process at one time. Also, when a P-IMAP client drops a connection or accidentally disconnects, the P-IMAP server can retain the associated session and cache all events during the time the client is disconnected. When the client reconnects and is able to obtain the same session, it does Maes Expires - August 2005 [Page 7] February 2005 not need to perform a state-comparison-based synchronization all over again, and the server sends the list of pending events to the client. In order to avoid losing changes performed on the client during the time the client is disconnected, the client should apply its changes first. 1.2.3. Reconnecting in a same session The IMAP protocol is predicated upon the assumption that the client establishes a session that is maintained during the client server interaction. However, the IMAP protocol depends on the underlying transport protocol to provide the session. Establishing a session is costly and attempts can be made to lower the cost via schemes like the quick reconnect technique being proposed for IMAP [CONNECT]. However, if the underlying transport is inherently unstable, such as over a wireless network, the transport protocol may drop the session frequently. Also if P-IMAP were to be implemented over sessionless protocol such as SMS, or asynchronous messaging system (e.g. MOM -- Message Oriented Middleware), then the session may not even be maintained by the underlying transport protocol. For this reason a future extension may allow P-IMAP commands to optionally carry a session ID in them so that the P-IMAP server can relate any command to the right session if it exists, or respond with the LOGIN response if the session does not exist. If the session exists, the P-IMAP client can behave as if it never lost the session to the server. This technique is immune to the characteristics of the underlying transport protocol from the perspective session reliability. One scheme to include a session id in P-IMAP commands is to encode them as a prefix of the tags. In this scheme, when the client logs in into the P-IMAP server with the device ID appended to the login name, it will establish a session and associate a unique id (SID) with the session. The SID is sent back to the P-IMAP client as part of the response to this type of LOGIN response. The P-IMAP client will then construct P-IMAP command tags using the SID as a prefix. For any P- IMAP command, the P-IMAP client may receive an untagged LOGIN response. In this case, the P-IMAP client must assume that the session to the server is severed and must take the appropriate action. So with such a scheme, the P-IMAP client must always assumes the session is still alive unless the P-IMAP server informs it otherwise. It therefore will behave like an online client until such time as the server returns a LOGIN response. Then it initiate the disconnected mode synchronization approach (i.e. start a state- comparison-based synchronization). Loss of session to the server does not necessarily mean the P-IMAP client has to resort to the state comparison based synchronization. It depends on the P-IMAP client and server capabilities. For example, Maes Expires - August 2005 [Page 8] February 2005 if the server supports UID based operations and is able to return EXPUNGE untagged responses with UIDs instead of message sequence numbers, the P-IMAP client may do event based synchronization as long as the UIDs are still valid for the folder. 1.3. The Server-Side Filtering in P-IMAP The P-IMAP protocol is meant to support mobile client devices with memory and connectivity constraints. Due to these constraints, an end user may want to specify filters to limit the number of notifications sent. These filters separate their emails into different sets that the server should handle differently. All end users have a complete repository, which includes all their email messages that are stored on a server. The end user may want to receive a small subset of these messages on their client device, which are to be included on the mobile device. The messages on the device are split further into two categories, lower priority messages that the user chooses to wait for until it can poll the server and higher priority messages that the user would like to be notified of as soon as possible by the server. All three repositories have the same set of folders. +----------------+ +--------------+ +------------+ | COMPLETE | | MOBILE | | MOBILE | | | | POLL | | PUSH | | REPOSITORY | View | REPOSITORY |Notification | REPOSITORY | | all the emails |Filters | emails to be | Filters | important | |in an end user's|=======>|on the mobile |============>| emails of | | email account | | device | | end user | +----------------+ +--------------+ +------------+ Figure 3: Filters and Repositories Formally, a repository consists of a set of folders, and each folder has both a name and a set of messages associated with it. While the three repositories all have folders with the same name, there may be different messages in them. The complete repository consists of all folders of an end user and all the associated emails for each of those folders. Messages in the complete repository that pass the view filter make up the poll repository. An end user can specify exactly one view filter per folder per device. In addition, there is a second layer of filtering, called notification filter, and there is exactly one notification filter per folder per device. The push repository is the set of all the messages in the complete repository that pass both the view and the notification filters. Maes Expires - August 2005 [Page 9] February 2005 From this point forth, it can be assumed that an event in this document refers to only and all changes to messages in the mobile repositories. When the client connects to the server and polls for messages, it can determine what changes have occurred to messages that passed the view filters. Whenever an event occurs to a message that passes the view and notification filters, the server actively pushes a notification to the client. Whenever a change occurs to the server, it is first determined whether this change concerns a message or a folder. If it concerns a folder, it is a folder event and all folder events are push events. If the change concerns a message that passes the view filters, it is a message event. Otherwise, this change does not concern the mobile repository and thus is not considered an event for the purposes of P- IMAP. Next, if a message event concerns a message that passed the notification filters and that event passes the event filter, it is a pushed message event. Otherwise, if the message event concerns a message that does not pass the notification filters or does not pass the event filter, it is a polled message event. 1.4. Extra Functionality in P-IMAP The P-IMAP server supports a rich set of extra functionality over the IMAP server to support extra features for a mobile client, and these features are presented: [1] Compression - The P-IMAP protocol allows for compression of responses to a command. Preliminary testing results shows significant performance results when the response to FETCH FLAGS or header information are compressed. [2] Sending emails - The P-IMAP server can be used to send email, thus eliminating the need for the P-IMAP client to connect to a separate SMTP server. [3] Support for unstable mobile connections - After a client drops a connection, the P-IMAP server can temporarily maintain the session for the mobile client. During this time, the server caches any events concerning the mobile repository while the client is disconnected, which it can then send to the client upon reconnection. [4] Longer periods of inactivity tolerated - A P-IMAP server can wait for certain period of time before logging out an inactive mobile client and ending its session. [5] Attachments forward/reply behavior - When forwarding/replying to a message from the P-IMAP client, the end user may choose to reattach the original's message attachments by just specifying the Maes Expires - August 2005 [Page 10] February 2005 UID of the original message and specifiers for the required bodyparts. The client need not download the attachments of the original message itself. This is an expected server behavior. [6] Attachments conversion - The P-IMAP server can convert attachments to other formats to be viewed on a mobile device. If the server knows the characteristics of the device or can determine them (out of scope of P-IMAP), the attachments can also be optimized for the capabilities of the devices (e.g. form factor of pictures). This is a recommended server behavior. [7] PIM - The protocol can also provide support for updating personal information on a client device, even when these changes are initiated from another client (i.e. a personal assistant connects to an end user's account from a desktop and changes contact information.) Vendors may rely on P-IMAP to exchange calendar events and address book changes as attachments or messages. No additional specification is provided as such formats are outside the scope of P-IMAP. In addition, alternate mobile PIM synchronization specifications exist and are widely deployed on mobile devices (e.g. [OMA DS]). 2. Relation with the Lemonade Profile and other E-mail specifications P-IMAP optimizes IMAP for mobile clients. It governs exchanges between mobile clients and servers. The Lemonade Profile [LEMONADEPROFILE] specifies the Lemonade Pull Model that governs the exchanges among mail servers or between desktop mail client and mail servers. Lemonade investigates adding mobile optimizations for the next version of the profile. P-IMAP should be seen as a way to address the issues of mobile optimization. This document assumes that clients MUST be compliant to P-IMAP. The Lemonade server MUST be compliant to the P-IMAP for its exchanges with the mobile client. Clients MAY follow the Lemonade Profile described in [LEMONADEPROFILE], if it is commonly understood by the client and the server as determined when exchanging CAPABILITY. Note that P-IMAP defines multiple bindings. When it relies on TCP bindings for P-IMAP requests and responses, P-IMAP can be viewed as a direct extension of IMAPv4 Rev1 (or IMAP4 profile for mobile) and therefore a good candidate for the Lemonade mobile optimization. With other bindings, it becomes a way to implement optimized mobile and push e-mail using IMAP semantics appropriately extended and transported on other bindings. On HTTP it is reminiscent to WEBDAV Maes Expires - August 2005 [Page 11] February 2005 with IMAP semantics but optimized for mobile and to support push e- mail. It is also possible to define profiles of client behavior for specific devices capabilities or network capabilities. 3. The P-IMAP Design P-IMAP extends IMAP and has the same basic model, where the client connects to the server to open a session to access its email account. A P-IMAP client may fetch the contents of the email account or make changes to it just as in IMAP. P-IMAP does, however, have many enhancements to IMAP, and this section introduces the core design changes. There are many requirements given in this section, as well as concepts that are essential to understanding the protocol. 3.1. Implementing Filters A P-IMAP server should support multiple mobile devices for each email user, and should allow each device to have one unique event filter and a set of view filters and notification filters. A mobile client connects to the P-IMAP server by supplying its LOGIN information, and then must inform the server of this mobile client's device ID, which is some unique identifier for the client device. The server and client should agree on what convention to use for this ID, and it could be a hash of IMEI. If no device ID is given, then a regular IMAP session is initiated instead of a P-IMAP session. The LOGIN information is used to specify a user, while the device ID is needed to specify the mobile client. Associated with the user and device ID is exactly one view filter and exactly one notification filter for each folder. These filters are saved and thus persist across P-IMAP sessions. Filters can be modified when a P-IMAP session is open. 3.1.1. The View Filter View filters are used to filter out email messages which match certain criteria. If an email passes through the view filter, it is stored in the mobile repository. The syntax for defining a view filter includes any combination of most of the search criteria as defined for the SEARCH command of IMAP, in Section 6.4.4 and 7.2.5 of RFC 3501, or a days filter. The days filter filters messages received starting a certain number of days before the current day. The ALL search criteria, when used alone, means that every email event satisfies the criteria. By default, view filters are set to ALL. Whenever a view filter is modified, the client needs to perform a state-comparison-based sync to keep in sync with the mobile Maes Expires - August 2005 [Page 12] February 2005 repository since the messages in the mobile repository may have changed. 3.1.2. The Notification Filter Notification filters are used to form a subset of higher priority messages by filtering out emails in the mobile repository which match certain criteria. If an email passes through the notification filter, it is stored in the push repository. The syntax for defining a notification filter is the same of defining a view filter and this additional filtering is applied onto the mobile repository Because the view filter defaults to ALL and the notification filter to NONE, the mobile repository will mirror the complete repository, but none of the messages are added to the push repository. This implies that the default behavior is equal to the IMAPv4 Rev1 model. The client does not need to do anything after it resets a notification filter or event filter. The server should then only send out notifications that correspond to the most up-to-date filters. 3.1.3. The Event Filter The event filter is used to filter out message events concerning messages in the push repository. The syntax for defining an event filter is ALL, NONE, or NEW. An event filter applies for all folders in a push repository. ALL -- All message events concerning messages of the push repository will be sent to the client, such as if the message becomes seen or deleted. NONE -- No events should be pushed to the client. NEW -- Only events that concern new messages arriving to the push repository should be pushed to the client. 3.2. Connectivity Models There are three connectivity models for P-IMAP, depending on the capabilities of the P-IMAP server, the client, and the connection available between them. These models include in-response, inband, and outband. It is explicitly stated in what situations these three connectivity models arise. 3.2.1. In-Response Connectivity The in-response binding scenario is the most basic one and implements the poll model. In this case the client initiates the commands to the P-IMAP server and the server responds to client commands with events. In this case there is no need for a persistent connection between the client and the server. The client opens a connection only when it Maes Expires - August 2005 [Page 13] February 2005 needs to send commands to the P-IMAP server, and that is the only time it is notified of new events. +--------+ +++ HTTP, etc. +--------+ | | Command +++ | | | Client |--------------------+++--------------->| P-IMAP | | Device | +++ | Server | | | Response + Event +++ | | | |<-------------------+++----------------| | +--------+ +++ +--------+ Figure 4: In-Response connection Cases of in-response connection: [1] HTTP/HTTPS binding - Server Requires: HTTP/HTTPS listener for P-IMAP - Client Requires: HTTP/HTTPS client with P-IMAP processing [2] TCP Binding - Server Requires: P-IMAP - Client Requires: P-IMAP + no IDLE 3.2.2. Inband Connectivity The inband binding scenario corresponds to a reliable push model. In this case the server pushes events to the client whenever they occur. To do so, it must have a reliable means of communication with the client, and the client should be ready to accept such notifications. In this case, there needs to be a persistent connection between the client and the server so that the server can push an event at any time. The client may optionally issue a request to retrieve more information concerning an event. +--------+ OOO TCP, Persistent +--------+ | | Push Event OOO HTTP, etc. | | | Client |<------------------OOO-----------------| P-IMAP | | Device | OOO | Server | | | Optional Request OOO | | | |...................OOO................>| | +--------+ OOO +--------+ Figure 5: Inband Connection Cases of inband connection: [1] TCP Binding, Always connected, IDLE - Server Requires: P-IMAP + IDLE - Client Requires: P-IMAP + IDLE, constant TCP connection [2] Any other persistent two-way connection - Server Requires: P-IMAP + IDLE on persistent connection (e.g HTTP/HTTPS) - Client Requires: P-IMAP + IDLE on persistent connection (e.g HTTP/HTTPS), constant connection Maes Expires - August 2005 [Page 14] February 2005 Persistent HTTP/HTTPS may sometimes be difficult to achieve with today’s intermediaries... Both connectivity models above (In-reponse and inband) involve a maintained data connection with notification exchanged within the P- IMAP “band” (i.e. P-IMAP exchanges). 3.2.3. Outband Connectivity This case coves notification outside the P-IMAP “band”: - In a different connection - Within the same data connection but outside the P-IMAP “band” The outband binding scenario corresponds to an push model that may be unreliable. In this case the server pushes events to the client whenever they occur, to the best of its ability. To do so, it should be able to send messages to the client without necessarily the need for a persistent connection. However, the outband channel can possibly lose and reorder messages, and there are no timing guarantees. Examples of out-band channels include SMS, JMS, WAP Push, SIP notification and UDP. As in the inband scenario, the client may optionally open a P-IMAP session over an inband or in-response connection and send a command as a result of receiving an event. +--------+ Push Event XXX SMS/SIP/MMS/ +--------+ | |<--------------XXX---------------------| | | Client | XXX /WAP Push/JMS/... | P-IMAP | | Device | Inband or | Server | | | Request +O+ In-response | | | |---------------O+O-------------------->| | +--------+ +O+ +--------+ Figure 6: Outband Connection Cases of outband connectivity: [1] A notification service from the server to the client - Server Requires: A notification generator. - Client Requires: A notification processor. Inband or In-response exchanges are on: - HTTP or HTTPS - TCP - Other transport 3.3. Recommended Connectivity Models Maes Expires - August 2005 [Page 15] February 2005 To address the problems discussed in [MEMAIL], it is a good idea to always support the outband connectivity model with HTTP/HTTPS binding. Support of HTTP/HTTPS binding is recommended as a minimum option. Recommended outband channels include SMS, UDP (if supported by target networks and deployment model) and SIP event notification all using the payload format discussed in appendix B. 3.4. Keeping the Client In Sync with the Mobile Repository Whenever a client device opens a new P-IMAP session, it must perform a state-comparison-based sync with the email server so that its state is the same as the mobile repository. Since the client has no way of directly detecting only changes to the repository since the last login, it needs to retrieve information about every message in the mobile repository and calculate the changes itself. After that point, the client can use event-based synchronization to keep the device in sync. The P-IMAP server can issue a session and track changes to a selected folder for the duration of a session. Until the session is expired, the server must log all events that occur while a client is disconnected. This way, if the client temporarily loses a connection, it does not have to worry about missing any events and needing to perform another state-comparison-based sync. A client does have the option though to prematurely end a session by issuing a LOGOUT command. Additionally, P-IMAP clients can remain inactive for a certain period of time without being logged off the server and without the session expiring. 4. Events This section contains the syntax that the server uses to send events to the client. 4.1. Message Events Sent During Inband and Inresponse Mode The client can receive the following untagged responses from the server: [1] The client receives an EXISTS/RECENT event from the server indicating a new message. S: * 501 EXISTS S: * 1 RECENT Next, the client retrieves this new message using a FETCH command. Maes Expires - August 2005 [Page 16] February 2005 C: A02 FETCH 501 (ALL BODY[]) S: * 501 FETCH ... S: A02 OK FETCH completed [2] The client receives an EXPUNGE event from the server from a message has been permanently removed from a folder. S: * 25 EXPUNGE The client deletes this message from the client device, as it has been removed permanently from the folder. The client does not need to send any command back to the server. [3] The client receives an untagged FETCH event from the server, which can contain just FLAG information if the event is regarding an old message or possibly other information if the event is regarding a new message. This event is received if a message's flags are changed, or in response to a new message if the user's preferences are set to do so. S: * 101 FETCH (FLAGS (\Seen \Deleted)) The client saves the information contained in this response accurately in the client device. 5. Interactions between the P-IMAP Client and P-IMAP Server A P-IMAP server must support all IMAPv4Rev1 commands from client devices following the syntax defined in [RFC3501]. Thus, a P-IMAP client may issue any existing IMAP commands to the P-IMAP server, and both the server and client must behave as specified in RFC3501 except for the changes specified in Section 5.1. In addition, P-IMAP defines extension commands for IMAPv4 Rev1 using the Experimental/Expansion mechanism defined in [RFC3501, Sec 6.5] and, as per RFC definition, P-IMAP command names must start with X. P-IMAP commands are tagged and asynchronous following the same rules as in IMAPv4 Rev1. Client commands, as well as the server responses to them, are included in this section. The P-IMAP protocol also defines events to be sent by the server to the client. These events notify the client when there are changes to messages that match an end user's view filters and notification filters, as well as any changes to a client's email folders. The syntax defined in this section is an abstract syntax, and payloads may vary according to the communication mechanism used. The normative appendix of this document describes some specific payloads. The format for presenting commands is defined as follows (SEE RFC3501]: Maes Expires - August 2005 [Page 17] February 2005 Formal Syntax: Valid States: [Extension to: ] Responses: Result: Example: C: S: This section describes commands where the client initiates contact with the server, like all the commands in the IMAPv4 Rev1 protocol. These commands include extensions to the IMAP protocol that have been created in order to better support mobile devices, and these extensions are all prefixed with X. They are used to perform actions on messages: retrieve, delete, search, etc., as well as set up the filters and notification methods of a mobile client. These commands are sent over a reliable connection as required for IMAP, see [RFC3501, Sec. 2.1] for more details. Client devices can send several commands at one time and, thus, these commands must be tagged. The server can send tagged and untagged responses to the client. Untagged responses contain information requested by a command. Tagged responses give the status of the command execution and its tag identifies the command it corresponds to. To connect to a P-IMAP server, the client must first follow the procedure for establishing an IMAP session. The client starts out in NOT AUTHENTICATED state and issues a LOGIN command with a valid P- IMAP device ID appended to the username. Firing this command enters the client into a P-IMAP session, where it can use all the P-IMAP Maes Expires - August 2005 [Page 18] February 2005 extension commands, as opposed to a regular IMAP session, which will return errors to all P-IMAP defined extensions other than XZIP, XDELIVER, and XPROVISION. To establish a regular IMAP session, the client may also login in the usual fashion with their username and password. The server responds to XPROVISION commands by returning any service specific parameters of the server, such as which outband channels are supported. The XZIP command can be used to zip the response to another command. XDELIVER allows the client to send an email message through this server, instead of having to connect with an SMTP server. Once entered into the P-IMAP session, the client can issue XFILTER, XCONVERT, XSETPIMAPPREF, XGETPIMAPPREFS, and XPSEARCH as needed. XFILTER is used to set the view filters and notification filters. XCONVERT is used for attachments conversion and XPSEARCH is an enhanced version of SEARCH in IMAPv4 Rev1. 5.1. Revisions to IMAPv4 Rev1 Behavior The section describes all the differences between how an IMAPv4 Rev1 server vs. a P-IMAP server responds to all IMAPv4Rev1 commands for implementing the custom mobile features. A compliant P-IMAP server must implement all the commands in IMAPv4 Rev1, with these revisions. The IMAPv4Rev1 syntax on commands and responses are found in sections 6 and 7 in [RFC3501]. The rest of this section defines any additional modifications to the IMAP commands that a P-IMAP server must implement to be compliant. 5.1.1. UID As specified in RFC 3501, section 2.3.1.1, "The unique identifier of a message MUST NOT change during the session, and SHOULD NOT change between sessions." Changing the UID of email messages imposes a very heavy computational burden on a mobile client. 5.1.2. Mobile Repository In a P-IMAP session, the client can only access messages in the mobile repository. This affects the messages returned by FETCH, UID FETCH, etc. Message sequence numbers reflect the relative position of messages within the given folders of the mobile repository, so the message sequence number of an email while logged in to P-IMAP may also differ from IMAP. When returning information about the email account, only messages in the mobile repository are taken into account. Maes Expires - August 2005 [Page 19] February 2005 5.1.3. The CAPABILITY Command The CAPABILITY command is defined in RFC3501, section 6.1.1. The client sends a CAPABILITY command so it can query the server to find out what commands it supports. In RFC3501, the IMAP server is allowed to specify additional capabilities not included in that specification. A P-IMAP server conforms to that requirement, and must list what P-IMAP version it supports. XPIMAPv1 means that the client supports PIMAP version 1, which includes the commands, XPROVISION, XSETPIMAPPREF, XGETPIMAPPREF, XDELIVER, XFILTER, XZIP and XCONVERT. A client can also enumerate individually the P-IMAP commands and additional commands that it supports. capability_cmd = tag SP "CAPABILITY" Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT Responses: REQUIRED untagged response: CAPABILITY Result: OK - capability completed BAD - command unknown or arguments invalid Example: A P-IMAP server that implements P-IMAP Version 1. C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE xPIMAPv1 S: a001 OK CAPABILITY completed 5.1.4. P-IMAP Session/Login An email user's LOGIN name for a P-IMAP session is its regular username + "#" + its P-IMAP device ID + the email domain. P-IMAP device IDs might be "P" + the client's digit telephone number (Note the length of the phone number should not be limited to a specific value as it may change from country to country). To enter a P-IMAP session, the client uses a LOGIN command with this new LOGIN name. The P-IMAP server will automatically try to resume a previous session for this client. It can rely on the new mechanisms described in section 1.2.3 otherwise the server can inform the client of the state of the server by sending an untagged SESSION response. If that state is SELECTED, the server also tells the client what the selected folder is by sending an untagged FOLDER response. Next, the server sends the client any pending events that have occurred in this folder while the client has been disconnected. Thus, the client can just service these pending events and need not perform a full sync. If these events could not be cached for some reason or the server senses the client may have not received some events, the RESYNC Response is returned, and the client should perform a state-comparison based Maes Expires - August 2005 [Page 20] February 2005 sync. A SESSIONID Response is returned whenever a PIMAP session is initiated/resumed. untagged SESSION Response = "*" SP "SESSION" SP ("AUTHENTICATED" / "SELECTED")untagged SESSIONID Response = ""*" SP "SESSION" SP untagged FOLDER Response = "*" SP "FOLDER" SP folder untagged RESYNC Response = "*" SP "RESYNC" When there is no active P-IMAP session - either because this is the very first time client logins, or because the client explicitly sent a LOGOUT command to close a previous session - then the server returns a new session ID response and the tagged response to the LOGIN command, and the client needs to perform state-comparison-sync to synchronize its contents. Example: First login, the client needs to perform a state- comparison-sync to get in sync. C: A01 LOGIN joe#P6505551234 password S: * SESSIONID 123456 S: A01 OK LOGIN completed Example: A successful P-IMAP login resuming an old session C: A02 LOGIN joe#P6505551234@foo.com password S: * SESSION AUTHENTICATED S: * SESSIONID 123456 S: A02 OK LOGIN completed Example: A successful P-IMAP login resuming an old session in SELECTED state with the INBOX selected. C: A02 LOGIN joe#P6505551234 password S: * SESSION SELECTED S: * FOLDER INBOX S: * 14 EXISTS S: * 49 FETCH (.... S: * SESSIONID 123456 S: A02 OK LOGIN completed Example: A successful P-IMAP login resuming an old session in SELECTED state with the INBOX selected, but where the server could not cache all the events since the last disconnect. C: A02 LOGIN joe#P6505551234 password S: * SESSION SELECTED S: * FOLDER INBOX S: * RESYNC S: * SESSIONID 123456 S: A02 OK LOGIN completed Maes Expires - August 2005 [Page 21] February 2005 5.1.5. IDLE The server should implement the IDLE command from RFC 2177. When the client issues this command, the server can push changes to a folder to the client. The server may replace the EXISTS/RECENT message with an untagged FETCH command as specified in Section 5.2.2. The client should fire this command while in-session to enter inband mode, where the server will actively push notifications to the client. 5.1.6. XENCRYPTED For certain proxy-based implementation of P-IMAP (see Security Considerations and Appendix C), it may be necessary to have only encrypted responses for retrieving email content. In that case in place of any untagged FETCH response, the P-IMAP server will return an untagged XENCRYPTED response with message content. The server should return XENCRYPTED in response to the CAPABILITY command if it implements this security mechanism and must announce the encryption methods specified (see the example following). untagged XENCRYPTED Response = "*" SP "XENCRYPTED" SP encrypted_message_data Server's response to the CAPABILITY command announcing XENCRYPTED methods. C: A02 CAPABILITY S: * CAPABILITY IMAP4rev1 XENCRYTPED=3DES,RC40,AES S: A02 CAPABILITY completed Keys and key updates can be provided via XPROVISION. See also the analysis presented in Appendix C. When the client registers itself with the server, it sends a HELLO message with the device ID in plain text and a payload, which is the device ID, encrypted using the encryption key associated with the server, to the Notification Delivery Service. The format of this message is: HELLO sp deviceID sp encrypted-deviceID network-characteristics Network-charateristics may be the device IP address or any other information the device wants to send. The server is expected to use what it understands and disregard the rest. The server will look up the encryption key associated with the device. If the encryption key does not exists, “INVALID ENCRYPTION KEY“ response is sent to the Notification Processor in plain text. If the encryption key exists the Notification Delivery Service will use Maes Expires - August 2005 [Page 22] February 2005 it to decrypt the payload using 64 bit Advanced Encryption Standard or 64-bit Triple-DES algorithms and compares it to the device ID. If they match, it will retrieve information that it has on the device. It will then send the OK response to the caller (client). When UDP notifications are used it will send with the encrypted server IP Address and port number of the Notification Delivery Service as described in XPROVISION. Whenever the server must send a notification to the client, the server generates a unique sequence number and content for the notification, encrypts it using the encryption key, and sends it to the device. The mechanism to send it may be a UDP/IP session if one is available to the device or any other outband message otherwise. When XENCRYPTED is used, all inband messages from the server are similarly encrypted. The client use the same key to encrypt its messages to the server. Note that if proxies are not an issue (see Appendix C and section on Security considerations), STARTTLS may be used by the client. In such cases, XENCRYPTED does not present any advantages and should not be used. 5.2. P-IMAP Extension Commands and Responses The following subsections define P-IMAP extension commands and as per RFC 3501, their names start with X. 5.2.1. XPROVISION The XPROVISION command is used to allow a device to obtain service specific parameters of the server. This includes what =filters have been defined. Also, it will supply a list of all P-IMAP preferences and the values they can be set to. For the special XFILTER preference, there are three things returned, the folders, the filter types, and the names of the xfilters supported. In addition, UDP information may be given when UDP notification is supported, such as the host name and port. A P-IMAP server can return other parameters as long as its syntax is agreed upon with the P-IMAP client. xprovision_cmd = tag SP "XPROVISION" SP device-id [notif-id] Valid States: AUTHENTICATED or SELECTED Responses: REQUIRED untagged responses XPROVISION Result: OK - provision completed NO - can't provision this device BAD - command unknown, invalid argument Maes Expires - August 2005 [Page 23] February 2005 untagged XPROVISION XFILTER response = "*" SP "XPROVISION" SP "XFILTER_GET" SP "(" ["DESC"] [SP "CRITERIA"]")" untagged XPROVISION XFILTER response = "*" SP "XPROVISION" SP "XFILTER_SET" SP "(" filter_criteria supported ")" untagged XPROVISION XPIMAPPREF response = "*" SP "XPROVISION" SP "XPIMAPPREF" SP prev-name SP "(" pref_val_list ")" untagged XPROVISION UDP_HOST response = "*" SP "XPROVISION" SP "PIMAP_UDP_HOST" SP "(" udp_hostname ")" untagged XPROVISION UDP_PORT response = "*" SP "XPROVISION" SP "PIMAP_UDP_PORT" SP "(" udp_portnum ")" untagged XPROVISION ENC_KEY response = "*" SP "XPROVISION" SP "PIMAP_ENC_KEY " SP "(" encryptionkey ")" Example: The client issues an XPROVISION command. The server returns that the client may get the description of a filter, cannot create any named xfilters (since the search criteria supported is empty), and also the values of various PIMAPPREF's and the values they can be set to. The server responds by returning the encryption key, modes, and channels supported by P-IMAP. Note the syntax for returning parameters. C: A002 XPROVISION S: * XPROVISION XFILTER_GET (DESC) S: * XPROVISION XFILTER_SET () S: * XPROVISION XPIMAPPREF PIMAP_OUTBAND_CHANNEL (SMS NONE) S: * XPROVISION XPIMAPPREF PIMAP_INBAND_NEW_FORMAT (NONE) S: * XPROVISION XPIMAPPREF PIMAP_INBAND_PUSH (ON OFF) S: * XPROVISION XPIMAPPREF XFILTER_FOLDER (INBOX) S: * XPROVISION XPIMAPPREF XFILTER_TYPE (B) S: * XPROVISION XPIMAPPREF XFILTER NAME (ALL URGENT PROFILE1) S: * XPROVISION XPIMAPPREF PIMAP_EVENT_FILTER (NEW) S: * XPROVISION XPIMAPPREF PIMAP_OUTBAND_FORMAT (EMN EXTENDED) S: * XPROVISION PIMAP_UDP_HOST (udp_hostname) S: * XPROVISION PIMAP_UDP_PORT (udp_portnum) S: * XPROVISION PIMAP_ENC_KEY (enc_key) S: A002 OK XPROVISION completed UDP HOST and UDP PORT define where the client initiates a UDP session for UDP notification. Event payloads are discussed in Appendix B. 5.2.2. XSETPIMAPPREF & XGETPIMAPPREFS The XSETPIMAPPREF command allows a user to define certain configuration parameters, while the XGETPIMAPPREFS command allows a user to retrieve the configuration values. Any server that implements these commands must respond with XPIMAPPREF as one of the capabilities in response to a CAPABILITY command. It must also announce the values these parameters can be set to in the XPROVISION Maes Expires - August 2005 [Page 24] February 2005 command as specified as follows. These parameters affect how outband notifications are sent to the client, as well as the format for sending new event notifications. If the server supports XPIMAPPREF they are required to support all of the following preferences. This command also allows the user to set active filters. By default, view filters are set to ALL, while notification filters are set to NOT ALL. This means that the mobile repository includes all the messages in the complete repository, but none are pushed to the client, which is the IMAPv4 Rev1 model. To set a filter, first the folder that that filter should be applied to, or "ALL" for all folders should be specified. Next the user specifies "V", "N", or "B" to set either a view filter or a notification filter, or both. Following this, it must specify the name of the filter for that folder. This filter may have been created by the XFILTER command, or be a system defined filter. Exactly one view filter and one notification filter is associated with each folder for each device. When a new view filter or notification filter is created, it replaces the previous filter for that folder. When a view filter is modified, the client needs to perform a state-comparison-based sync on the client in order for the device to be in sync with the mobile repository. The server always sends only notifications that correspond to the most up-to-date view filters and notification filters. All filters persist across P-IMAP sessions; once set, a filter on a folder applies until the user changes it. The preferences that can set with this command are as follows and their names start with PIMAP to identify them as P-IMAP parameters. (They may not apply in some configuration (e.g. no PIMAP OUTBAND ADDRESS when using UDP notifications)): [1] PIMAP_OUTBAND_ADDRESS - the number or email address to send SMS/JMS notification messages to the client or the address where to send SIP notifications. This must be a valid number or email according to the outband channel requirements. This will not be returned in the XPROVISION command. This is not applicable to outband UDP notifications. [2] PIMAP_OUTBAND_CHANNEL - the channel to send outband notifications, either SMS, JMS, WAP_PUSH, MMS, SIP, UDP or NONE. When NONE, the P-IMAP server does not send the client any outband notifications. The list of values may be extended when different outband channels are available. The valid values for this preference that the server supports will be given in response to the XPROVISION command. [3] PIMAP_INBAND_NEW_FORMAT - the FETCH parameters to automatically send to the client when there is a new message and there is a valid P-IMAP session, or NONE. If NONE, the server sends the client a Maes Expires - August 2005 [Page 25] February 2005 traditional EXISTS message when a new message arrives in the folder. Otherwise, in place of the EXISTS message, the server sends an untagged FETCH response with the given information. The valid values for this preference that the server supports will be given in response to the XPROVISION command. [4] PIMAP_INBAND_PUSH - whether or not the server should automatically IDLE the server when a folder is selected. The valid values for this preference that the server supports will be given in response to the XPROVISION command. [5] PIMAP_OUTBAND_FORMAT - the format to send the outband notifications, i.e. EMN or EXTENDED. [6] PIMAP_EVENT_FILTER - The event filter for this user. Possible values are ALL or NONE or NEW, depending on the server's capabilities. [7] PIMAP_XFILTER - Sets a named filter as the active filter for a given folder. The value of this parameter includes the folder, filter type (possibly VIEW, NOTIF, or BOTH depending on server capabilities), and the name of the XFILTER. xgetpimappref_cmd = tag SP "XGETPIMAPPREFS" SP "(" pimap_pref_list ")" pimap_pref_list = pimap_pref [SP pimap_pref_list] pimap_pref = (PIMAP_OUTBAND_ADDRESS / PIMAP_OUTBAND_CHANNEL / PIMAP_INBAND_NEW_FORMAT / PIMAP_INBAND_PUSH / PIMAP OUTBAND FORMAT / PIMAP_EVENT_FILTER / PIMAP_XFILTER) Valid States: AUTHENTICATED or SELECTED Responses: REQUIRED untagged XGETPIMAPPREFS response with the value of the requested parameter. untagged XGETPIMAPPREFS response - "*" XGETPIMAPPREFS pref-pair pref-pair = "(" pimap-pref SP pimap-pref-val [pref-pair] ")" Result: OK - command completed NO - command failure: can't alter preference BAD - command unknown or arguments invalid Example: The client wishes to know the current outband notification method it has set up. It sends an XGETPIMAPPREFS command. C: A003 XGETPIMAPPREFS (PIMAP_OUTBAND_CHANNEL) S: * XGETPIMAPPREFS (PIMAP_OUTBAND_CHANNEL SMS) S: A003 0K XGETPIMAPPREFS completed Example: The client wishes to know the current active xfilters. C: A003 XGETPIMAPPREFS (PIMAP_XFILTER) S: * XGETPIMAPPREFS (PIMAP_XFILTER (INBOX V ALL) Maes Expires - August 2005 [Page 26] February 2005 PIMAP_XFILTER (INBOX N PROFILE1) PIMAP_XFILTER (FOLDER2 B ALL)) S: A003 0K XGETPIMAPPREFS completed xsetpimappref_cmd = tag SP "XSETPIMAPPREF" SP (("PIMAP_OUTBAND_ADDRESS" SP device_address) / ("PIMAP_OUTBAND_CHANNEL" SP ("SMS"/"JMS"/"WAP_PUSH"/ "MMS"/"UDP" /"SIP" / "NONE")) / ("PIMAP_INBAND_NEW_FORMAT" SP fetch_criteria) / ("PIMAP_INBAND_PUSH" SP ("ON" / "OFF")) / ("PIMAP_OUTBAND_FORMAT SP ("EMN" / "EXTENDED")) / ("PIMAP_XFILTER" SP xfilter_value) xfilter_value = "(" mailbox SP ("V"/"N"/"B") SP xfilter_name) Valid States: AUTHENTICATED or SELECTED Responses: No specific responses. Result: OK - command completed NO - command failure: can't get a preference BAD - command unknown or arguments invalid Example: The client sets up its SMS device address and then selects that it wants SMS messages sent to the device, and the format of the SMS's it wants. It also sets the view and notification filters for the inbox to an XFILTER named PROFILE1. C: A002 XSETPIMAPPREF PIMAP_OUTBAND_ADDRESS 13335559999 S: A002 OK XSETPIMAPPREF completed C: A003 XSETPIMAPPREF PIMAP_OUTBAND_CHANNEL SMS S: A003 OK XSETPIMAPPREF completed C: A004 XSETPIMAPPREF PIMAP_OUTBAND_FORMAT EXTENDED S: A004 OK XSETPIMAPPREF completed C: A005 XSETPIMAPPREF XFILTER (INBOX B PROFILE1) S: A005 OK XSETPIMAPPREF completed. Example: The client sets the inband NEW format to be ALL, meaning it wants the server to automatically send it all the headers for any new message. C: A002 XSETPIMAPPREF PIMAP_INBAND_NEW_FORMAT ALL S: A002 OK XSETPIMAPPREF PIMAP_INBAND_NEW_FORMAT completed From now on, whenever a new message arrives in a folder during a valid P-IMAP session, the server will try to send an untagged FETCH response of the new message with the specified information to the client at the earliest opportunity. This untagged FETCH response replaces the untagged EXISTS response that IMAP sends regarding a new message. S: * 60 FETCH ... Maes Expires - August 2005 [Page 27]