Lemonade Internet Draft: Lemonade Command Extensions S. H. Maes Document: draft-maes-lemonade-command-extensions- R. Lima 00 C. Kuang R. Cromwell V. Ha E. Chiu Oracle Corporation Expires: January 2005 July 2004 Lemonade Command Extensions Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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." 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 The Lemonade Command Extensions 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. It proposes extensions for message delivery, and maintaining up-to-date personal information. Bindings to specific transport are explicitly defined. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Maes [Page 1] July 2004 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..........................................................1 Conventions used in this document.................................1 Table of Contents.................................................2 1. Introduction...................................................2 1.1. Extra Functionality by Lemonade Command Extensions........3 2. Interactions between the Lemonade Client and Lemonade Server...4 2.1. Revisions to IMAPv4 Rev1 Behavior.........................5 2.1.1. UID..................................................5 2.1.2. Mobile Repository....................................6 2.1.3. The CAPABILITY Command...............................6 2.1.4. Lemonade Session/Login...............................7 2.1.5. LEMONADEENCRYPTED....................................8 2.2. Lemonade Command Extensions Responses.....................8 2.2.1. LEMONADEPROVISION....................................8 2.2.2. LEMONADESETPREF & LEMONADEGETPREFS...................9 2.2.3. LEMONADEFILTER......................................11 2.2.4. LEMONADEZIP.........................................11 2.2.5. LEMONADEDELIVER.....................................12 2.2.6. LEMONADECONVERT & UID LEMONADECONVERT...............13 2.2.7. LEMONADEPSEARCH.....................................14 Security Considerations..........................................15 References.......................................................15 Non-Normative Appendices.........................................16 A. Security Issues for Proxy-Based Implementations of Lemonade16 Authors Addresses................................................17 Intellectual Property Statement..................................18 Full Copyright Statement.........................................19 1. Introduction Maes Expires - January 2005 [Page 2] July 2004 Lemonade Command Extensions protocol 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. The Lemonade Command Extensions take into account the limited resources of mobile devices, as well as extra functionality desired. 1.1. Extra Functionality by Lemonade Command Extensions The Lemonade 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 ū Lemonade 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 Lemonade server can be used to send email, thus eliminating the need for the Lemonade client to connect to a separate SMTP server. [3] Support for unstable mobile connections ū After a client drops a connection, the Lemonade 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 Lemonade server should wait at least 24 hours before logging out an inactive mobile client and ending its session. [5] Attachments forward/reply behavior - When forwarding/replying to a message from the Lemonade client, the end user may choose to reattach the original's message attachments by just specifying the UID of the original message. The client need not download the attachments of the original message itself. [6] Attachments conversion - The Lemonade server can convert attachments to other formats to be viewed on a mobile device. [7] PIM - The protocol also provides 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.) These additional uses are especially useful for mobile devices, where end users need up-to-date information on the fly. Maes Expires - January 2005 [Page 3] July 2004 2. Interactions between the Lemonade Client and Lemonade Server A Lemonade server must support all IMAPv4 Rev1 commands from client devices following the syntax defined in [RFC3501]. Thus, a Lemonade client may issue any existing IMAP commands to the Lemonade server, and both the server and client must behave as specified in RFC3501 except for the changes specified in Section 2.1. In addition, we define the following extension commands for IMAPv4 Rev1. Lemonade Command Extension are tagged and asynchronous following the same rules as in IMAPv4 Rev1. The format for presenting commands is defined as follows: 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 LEMONADE. They are used to perform Maes Expires - January 2005 [Page 4] July 2004 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 Lemonade 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 Lemonade device ID appended to the username. Firing this command enters the client into a Lemonade session, where it can use all the Lemonade extension commands, as opposed to a regular IMAP session, which will return errors to all Lemonade defined extensions other than LEMONADEZIP, LEOMONADEDELIVER, and LEMONADEPROVISION. To establish a regular IMAP session, the client may also login in the usual fashion with their username and password. The server responds to LEMONADEPROVISION commands by returning any service specific parameters of the server, such as which outband channels are supported. The LEMONADEZIP command can be used to zip the response to another command. LEMONADEDELIVER allows the client to send an email message through this server, instead of having to connect with an SMTP server. Once entered into the Lemonade session, the client can issue LEMONADEFILTER (see [NOTIFICATIONS]), LEOMONADECONVERT, LEMONADESETPREF, LEMONADEGETPREFS, and LEMONADEPSEARCH as needed. LEMONADEFILTER is used to set the view filters and notification filters. LEMONADECONVERT is used for attachments conversion and LEMONADEPSEARCH is an enhanced version of SEARCH in IMAPv4 Rev1. 2.1. Revisions to IMAPv4 Rev1 Behavior The section describes all the differences between how an IMAPv4 Rev1 server vs. a Lemonade server responds to all IMAPv4Rev1 commands for implementing the custom mobile features. A compliant Lemonade 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 Lemonade server must implement to be compliant. 2.1.1. UID Maes Expires - January 2005 [Page 5] July 2004 The UID of email messages MUST not change across sessions. Changing the UID of email messages requires a heavy computational burden on the mobile client, so the server should avoid doing so. 2.1.2. Mobile Repository In a Lemonade 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 Lemonade may also differ from IMAP. When returning information about the email account, only messages in the mobile repository are taken into account. 2.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 Lemonade server conforms to that requirement, and must list what Lemonade commands it supports. Minimally, this must include LEMONADEZIP, LEMONADEDELIVER, and either IDLE or outband notification. LEMONADEZIP capability is also returned independently of the binding. 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 Lemonade server that implements all Lemonade commands described in this document and in [NOTIFICATIONS]. C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LEMONADECONVERT LEMONADEFILTER LEMONADEPSEARCH LEMONADEZIP LEMONADEDELIVER LEMONADEPROVISION LEMONADEPREF S: a001 OK CAPABILITY completed Example: A minimal Lemonade server over TCP binding. C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LEMONADEZIP LEMONADEDELIVER S: a001 OK CAPABILITY completed Maes Expires - January 2005 [Page 6] July 2004 2.1.4. Lemonade Session/Login An email userĘs LOGIN name for a Lemonade session is its regular username + "#" + its Lemonade device ID + optionally, the email domain. Lemonade device IDs might be "P" + the clientĘs 10 digit telephone number. To enter a Lemonade session, the client uses a LOGIN command with this new LOGIN name. The Lemonade server will automatically try to resume a previous session for this client. If this is the case, the server informs 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 sync. untagged SESSION Response = "*" SP "SESSION" SP ("AUTHENTICATED" / "SELECTED") untagged FOLDER Response = "*" SP "FOLDER" SP folder untagged RESYNC Response = "*" SP "RESYNC" When there is no active Lemonade 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 only 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: A01 OK LOGIN completed Example: A successful Lemonade login resuming an old session C: A02 LOGIN joe#P6505551234@foo.com password S: * SESSION AUTHENTICATED S: A02 OK LOGIN completed Example: A successful Lemonade 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 (.... Maes Expires - January 2005 [Page 7] July 2004 S: A02 OK LOGIN completed Example: A successful Lemonade 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: A02 OK LOGIN completed 2.1.5. LEMONADEENCRYPTED For certain proxy-based implementation of Lemonade (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 Lemonade server will return an untagged LEMONADEENCRYPTED response with message content. The server should return LEMONADEENCRYPTED in response to the CAPABILITY command if it implements this security mechanism and must announce the encryption methods specified (see the example following). untagged LEMONADEENCRYPTED Response = "*" SP "LEMONADEENCRYPTED" SP encrypted_message_data Server's response to the CAPABILITY command announcing LEMONADEENCRYPTED methods. C: A02 CAPABILITY S: * CAPABILITY IMAP4rev1 LEMONADEENCRYTPED=3DES,RC40,AES S: A02 CAPABILITY completed 2.2. Lemonade Command Extensions Responses The following subsections define Lemonade Command Extension. 2.2.1. LEMONADEPROVISION The LEMONADEPROVISION command is used to allow a device to obtain service specific parameters of the server. This includes what LEMONADEFILTERS (see [NOTIFICATIONS]) are supported, since a server may not actually be able to support all IMAPv4Rev1 Search criteria. Also, it will supply a list of all Lemonade preferences and the values they can be set to. A Lemonade server can return other parameters as long as its syntax is agreed upon with the Lemonade client. Maes Expires - January 2005 [Page 8] July 2004 lemonadeprovision_cmd = tag SP "LEMONADEPROVISION" SP device-id [notif-id] Valid States: AUTHENTICATED or SELECTED Responses: REQUIRED untagged responses LEMONADEPROVISION Result: OK - provision completed NO - can't provision this device BAD - command unknown, invalid argument untagged LEMONADEPROVISION LEMONADEFILTER response = "*" SP "LEMONADEPROVISION" SP "LEMONADEFILTER" SP "(" filter_criteria_list ")" untagged LEMONADEPROVISION LEMONADEPREF response = "*" SP "LEMONADEPROVISION" SP "LEMONADEPREF" SP prev-name SP "(" pref_val_list ")" Example: The client issues an LEMONADEPROVISION command. The server responds by returning the encryption key, modes, and channels supported by Lemonade. Note the syntax for returning parameters. C: A002 LEMONADEPROVISION S: * LEMONADEPROVISION LEMONADEFILTER (AND OR DAYSBEFORETODAY HEADER FROM TO CC) S: * LEMONADEPROVISION LEMONADEPREF LEMONADE_OUTBAND_CHANNEL (SMS NONE) S: * LEMONADEPROVISION LEMONADEPREF LEMONADE_INBAND_NEW_FORMAT (NONE) S: * LEMONADEPROVISION LEMONADEPREF LEMONADE_INBAND_PUSH (ON OFF) S: A002 OK LEMONADEPROVISION completed 2.2.2. LEMONADESETPREF & LEMONADEGETPREFS The LEMONADESETPREF command allows a user to define certain configuration parameters, while the LEMONADEGETPREFS command allows a user to retrieve the configuration values. Any server that implements these commands must respond with LEMONADEPREF 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 LEMONADEPROVISION command as specified as follows. These parameters affect how outband notifications (See [NOTIFICATIONS]) are sent to the client, as well as the format for sending new event notifications (See [NOTIFICATIONS]). If the server supports LEMONADEPREF they are required to support all of the following preferences with at least one value to set each preference to. They are listed following and their names start with LEMONADE to identify them as LEMONADE parameters: Maes Expires - January 2005 [Page 9] July 2004 [1] LEMONADE_OUTBAND_ADDRESS - the number or email address to send SMS/JMS notification messages to the client. This must be a valid number or email according to the outband channel requirements. This will not be returned in the LEMONADEPROVISION command. [2] LEMONADE_OUTBAND_CHANNEL - the channel to send outband notifications, either SMS, JMS, WAP_PUSH, MMS, or NONE. When NONE, the LEMONADE 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 LEMONADEPROVISION command. [3] LEMONADE_INBAND_NEW_FORMAT - the FETCH parameters to automatically send to the client when there is a new message and there is a valid Lemonade session, or NONE. If NONE, the server sends the client a 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 LEMONADEPROVISION command. [4] LEMONADE_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 LEMONADEPROVISION command. lemonadegetpref_cmd =tag SP "LEMONADEGETPREFS" SP "(" lemonade_pref_list ")" lemonade_pref_list = lemonade_pref [SP lemonade_pref_list] lemonade_pref = (LEMONADE_OUTBAND_ADDRESS / LEMONADE_OUTBAND_CHANNEL / LEMONADE_INBAND_NEW_FORMAT / LEMONADE_INBAND_PUSH) Valid States: AUTHENTICATED or SELECTED Responses: REQUIRED untagged LEMONADEGETPREFS response with the value of the requested parameter. untagged LEMONADEGETPREFS response - "*" LEMONADEGETPREFS pref- pair pref-pair = "(" lemonade-pref SP lemonade-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 LEMONADEGETPREFS command. C: A003 LEMONADEGETPREFS (LEMONADE_OUTBAND_CHANNEL) S: * LEMONADEGETPREFS (LEMONADE_OUTBAND_CHANNEL SMS) S: A003 0K LEMONADEGETPREFS completed Maes Expires - January 2005 [Page 10] July 2004 lemonadesetpref_cmd = tag SP "LEMONADESETPREF" SP (("LEMONADE_OUTBAND_ADDRESS" SP device_address) / ("LEMONADE_OUTBAND_CHANNEL" SP ("SMS"/"JMS"/"WAP_PUSH"/ "MMS"/"NONE")) / ("LEMONADE_INBAND_NEW_FORMAT" SP fetch_criteria) / ("LEMONADE_INBAND_PUSH" SP ("ON" / "OFF")) 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. C: A002 LEMONADESETPREF LEMONADE_OUTBAND_ADDRESS 13335559999 S: A002 OK LEMONADESETPREF completed C: A003 LEMONADESETPREF LEMONADE_OUTBAND_CHANNEL SMS S: A003 OK LEMONADESETPREF 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 LEMONADESETPREF LEMONADE_INBAND_NEW_FORMAT ALL S: A002 OK LEMONADESETPREF LEMONADE_INBAND_NEW_FORMAT completed From now on, whenever a new message arrives in a folder during a valid Lemonade 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 ... 2.2.3. LEMONADEFILTER See [NOTIFICATIONS]. 2.2.4. LEMONADEZIP The LEMONADEZIP command is used for zipping the response of a command and can be used while the server is in any state. The LEMONADEZIP command takes in a complete second command (including a tag for that command). In an untagged response to LEMONADEZIP, the server gives the number of bytes in the zipped response to the second command, as well as the response to that command in g-zip format. Maes Expires - January 2005 [Page 11] July 2004 LEMONADEZIP is optional when HTTP/HTTPS binding is used as specified in [NOTIFICATIONS], as the Lemonade server may rely on the HTTP/HTTPS compression mechanism. For the other bindings LEMONADEZIP is mandatory. lemonadezip_cmd = tag SP "LEMONADEZIP" SP command Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT Responses: "{" num "}" zipped-response-to-command Result: OK - the command given was g-zipped correctly and sent BAD - invalid arguments, i.e. command given is in the wrong format. Example: Zipping the response to a FETCH command. C: A001 LEMONADEZIP A002 FETCH 1:* ALL S: * {10933843723} ...[zipped response to FETCH command]... CRLF S: A001 OK LEMONADEZIP completed When the client unzips the body of the response to the FETCH command it gets: * 1 FETCH ... ... A002 OK FETCH completed 2.2.5. LEMONADEDELIVER The LEMONADEDELIVER command can be used for creating new messages, or replying to/forwarding an existing message. The first argument after the command name indicates whether this is a new message "N", a reply "R" or a forward "F" of an existing message. When replying/forwarding a message, the client must specify the UID of the message being replied to or forwarded and whether or not to include the attachments of the original message in the reply/forward, by indicating either "Y" or "N" after the UID parameter. The text of the message being replied to/forwarded is automatically appended to the end of the new message regardless. If the user wishes to save a copy of this message to some folder, it can specify that next by using "SAVETO" followed by the name of the folder. If and only if SAVETO is specified, the server will return an APPENDUID response code with the UID validity and then the UID of that saved message in that folder. If the message cannot be saved to the server, an okay response will still be returned, but without a UID. The last argument of the LEMONADEDELIVER command is a number in braces that denotes the number of bytes in the Internet message (conforming to RFC 2822) that is to follow. A "+" before the closing braces means the client will send a CRLF and then the Internet message immediately, without waiting for a continuance response from the server. The server continues to wait until it receives the number of bytes specified, and then waits for an additional CRLF. If more bytes were input before this additional CRLF than was specified, the server returns an error. Thus, the client should input exactly the number of bytes specified for the Maes Expires - January 2005 [Page 12] July 2004 Internet Address, and then one final CRLF to terminate the LEMONADEDELIVER. lemonadedeliver_cmd =tag SP "LEMONADEDELIVER" SP ("N" / ("R"/"F") SP folder SP uid SP ("Y" / "N")) [SP "SAVETO=" folder] SP "{" number ["+"] "}" internet_msg Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT Responses: no specific responses Result: OK - mail delivered successfully by the SMTP server, LEMONADEDELIVERUID response code included if the SAVETO is included in the command. BAD - invalid arguments, for example missing parameter. NO - when the envelope information is invalid Example: new message C: A001 LEMONADEDELIVER N SAVETO=~/Sent {299} Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) From: Fred Foobar Subject: afternoon meeting To: mooch@owatagu.siam.edu Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello Joe, do you think we can meet at 3:30 tomorrow? A new message is prepared and sent. S: A001 OK LEMONADEDELIVER [APPENDUID 1 140] completed Example: reply message C: A001 LEMONADEDELIVER R Inbox 203 Y {299} Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) From: Fred Foobar Subject: afternoon meeting To: mooch@owatagu.siam.edu Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello Joe, do you think we can meet at 3:30 tomorrow? A reply message for message 203 is prepared and includes all original attachments. S: A001 OK LEMONADEDELIVER completed 2.2.6. LEMONADECONVERT & UID LEMONADECONVERT LEMONADECONVERT and LEMONADEUIDCONVERT is used for attachments conversion. In this case, the client sends one message sequence Maes Expires - January 2005 [Page 13] July 2004 number or UID, a body part number, and gives the mime-type and subtype to convert the attachment to. lemonadeconvert_cmd = tag SP "LEMONADECONVERT" message-sequence- number SP part-id SP "as" SP mime-type "/" subtype Valid States: SELECTED Responses: untagged responses: LEMONADECONVERT Untagged lemonadeconvert response = "*" SP message-sequence-number SP "LEMONADECONVERT" SP document_in_converted_format Result: OK - lemonadeconvert completed NO - lemonadeconvert error: can't perform the command BAD - command unknown or arguments invalid Example: The client fetches an attachment in the message with the message sequence number of 120 in the Inbox and asks to have that attachment converted to pdf format. C: a001 LEMONADECONVERT 120 BODY[3] as application/pdf S: * 2 LEMONADECONVERT S: a001 OK LEMONADECONVERT COMPLETED lemonadeuidconvert_cmd =tag SP "UID" SP "LEMONADECONVERT" uid SP part-id SP "as" SP mime-type "/" subtype Valid States: SELECTED Responses: untagged responses: LEMONADECONVERT Result: OK - lemonadeuidconvert completed NO - lemonadeuidconvert error: can't perform the command BAD - command unknown or arguments invalid Example: The client fetches an attachment in the message with UID 120 (and message sequence number 2) in the Inbox and asks to have that attachment converted to pdf format. C: a001 UID LEMONADECONVERT 120 BODY[3] as application/pdf S: * 2 LEMONADECONVERT S: a001 OK UID LEMONADECONVERT COMPLETED 2.2.7. LEMONADEPSEARCH The LEMONADEPSEARCH command and response syntax follows the same rules as the ones defined for the SEARCH command in RFC3501, Sec. 6.4.4 and 7.2.5 respectively. The LEMONADEPSEARCH command extension allows the search to be made persistent on the server and to appear as a virtual folder. Following the successful execution of an LEMONADEPSEARCH command, a new folder appears when using the LIST command under the root folder with the specific folder name requested. This new folder needs to be created on the client device. Clients operating on this folder see a view of the underlying folder with only messages matching the search criteria displayed. Operations on messages in this folder do not affect that message. Maes Expires - January 2005 [Page 14] July 2004 lemonadepsearch_cmd = tag SP "LEMONADEPSEARCH" [SP "CHARSET" SP astring] 1*(SP search-key) Valid States: SELECTED Extension to: UID SEARCH command [RFC 3501, Sec. 6.4.4] Responses: no specific responses Result: OK ū lemonadepsearch created NO - can't create the folder or incorrect query BAD - invalid arguments Example: create a persistent search for all messages from "John" since Jun, 1st 2003. The newly created folder name is called "from_john" C: A001 LEMONADEPSEARCH from_john FLAGGED SINCE 1-Jun-2003 FROM "John" S: A001 OK LEMONADEPSEARCH completed Security Considerations The protocol calls for the same security requirements for an in- response and inband connectivity mode as IMAP. For the outband connectivity mode, servers should use encryption methods for notifications if sensitive information is included in the payload of that notification. When an implementation of Lemonade is proxy-based, this may create new security issues. These issues are discussed in detail in Appendix A, because the issues are dependent on the implementation of this protocol rather than inherent to the protocol itself. References [OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August 2002. http://www.openmobilealliance.org/tech/docs/EmailNot/OMA- Push-EMN-V1_0-20020830-C.pdf [IMAP-DISC] Austein, R. "Synchronization Operations For Disconnected Imap4 Clients", IMAP-DISC, November 1994. http://asg.web.cmu.edu/cyrus/rfc/draft-ietf-imap-disc-01.html [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119 Maes Expires - January 2005 [Page 15] July 2004 [RFC2180] Gahrns, M. "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997. http://www.ietf.org/rfc/rfc2180 [RFC2234] Crocker, D. and Overell, P. "Augmented BNF for Syntax Specifications", RFC 2234, Nov 1997. http://www.ietf.org/rfc/rfc2234 [RFC2420] Kummert, H. "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. http://www.ietf.org/rfc/rfc2420 [RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. http://www.ietf.org/rfc/rfc2616 [RFC2617] Franks, J. et al. "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. http://www.ietf.org/rfc/rfc2617 [RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683 Sep 1999. http://www.ietf.org/rfc/rfc2683 [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997. http://www.ietf.org/rfc/rfc2177 [RFC2818] Rescorla, E. "HTTP over TLS", RFC 2818, May 2000. http://www.ietf.org/rfc/rfc2818 [RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April 2001. http://www.ietf.org/rfc/rfc2822 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 [NOTIFICATIONS] Maes, S.H. and Wilson C., "Lemonade Server to Client Notifications", draft-ietf-lemonade-server-to-client- notifications-00.txt, (work in progress), July 2004. Non-Normative Appendices A. Security Issues for Proxy-Based Implementations of Lemonade In some implementations of Lemonade, the client may connect to a proxy that sits in an operator network, but the backend email storage Maes Expires - January 2005 [Page 16] July 2004 server sits in a separate enterprise network. The enterprise network is assumed to be secure, but the operator network may not be trusted. If unencrypted information lies in the operator network, that information is vulnerable to attacks. If the Lemonade extensions are all implemented in the enterprise network, then the proxy on the carrier should be an encrypted SSL pass-through proxy. The proxy is unaware of the encryption keys and thus cannot encrypt any data. Without the encryption key, this proxy cannot see any of the information sent from the client, nor can it send any bogus commands to the backend enterprise email server to corrupt the user's mailbox. The additional cost for this design is that the backend enterprise email server and the client devices must have additional processing to handle this encryption. If the Lemonade server is implemented as a backend IMAP server with additional command processing done on the proxy, there are more complex security issues. This proxy must be able to send commands to the backend server to accomplish its tasks, as well as read information coming from the backend server. An attacker thus can send commands to the backend to change the state of the mail storage, possibly corrupting it. In addition, it can read responses from the mail server that might contain confidential email information. This proxy may also send bogus responses back to the client. Clearly, this setup is not an ideal issue and many complications that make this problem complex to solve. The suggestion recommended is to remedy the problem of unencrypted, untagged FETCH responses that may contain confidential information. Untagged LEMONADEENCRYPTED responses (see Section 2.1.5) should be used in place of any untagged FETCH responses, which contain encrypted message information to be passed through the lemonade proxy on the operator network. The key exchange for encryption should not occur through the proxy. It has to be done through another channel: manually entered by user (e.g. password), or via an HTTP SSL request to the enterprise server. Any other additional server responses containing sensitive information (passwords, etc.) should be LEMONADEENCRYPTED. The server should implement 3DES encryption and use the client's password as the key. Authors Addresses Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Maes Expires - January 2005 [Page 17] July 2004 Rodrigo Lima Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Chang Kuang Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Vida Ha Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Eugene Chiu Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice Maes Expires - January 2005 [Page 18] July 2004 this standard. Please address the information to the IETF Executive Director. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Full Copyright Statement Copyright (C) The Internet Society 2003. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Maes Expires - January 2005 [Page 19]