< Lemonade Notifications and Filters> March 2006 Lemonade Internet Draft: Lemonade Notifications and S. H. Maes Filters Document: draft-ietf-lemonade-notifications- 01.txt Expires: September 2006 March 2006 Lemonade notifications and filters Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses how to provide notification and filtering mechanisms to IMAP [RFC3501] as part the Lemonade profile [LEMONADEPROFILEBIS]. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Maes Expires - September 2006 [Page 1] < Lemonade Notifications and Filters> March 2006 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 Copyright Notice..................................................1 Abstract..........................................................1 Conventions used in this document.................................1 Table of Contents.................................................2 1. Introduction...................................................3 2. Objectives.....................................................3 3. Notification logical architecture and LEMONADE Profile phase 2.4 4. Capability Descriptions........................................5 5. Event-based synchronization....................................6 6. Filters........................................................7 6.1. Next steps and future work................................7 7. Inband notification payload....................................7 8. Outband Notification payload...................................7 8.1. Outband Notification Payload in Clear Text................8 8.2. Encrypted outband notifications..........................10 9. LEMONADE message store behavior...............................10 10. Checking notification settings...............................10 11. Changing notification settings...............................10 12. LPROVISION...................................................11 12.1.1. LSETPREF & LGETPREFS...............................12 13. Changing filters from the client.............................14 14. Out of scope items for IETF..................................14 Security Considerations..........................................15 References.......................................................15 Appendix A.Out-of-band SMS channel binding (INFORMATIVE appendix)16 Future Work......................................................17 Version History..................................................17 Acknowledgments..................................................17 Authors Addresses................................................18 Intellectual Property Statement..................................18 Disclaimer of Validity...........................................18 Maes Expires - September 2006 [Page 2] < Lemonade Notifications and Filters> March 2006 Copyright Statement..............................................19 Acknowledgement..................................................19 1. Introduction As the work on LEMONADE Profile ([LEMONADEPROFILE] and [LEMONADEPROFILEBIS]) progresses, a need has been identified to provide notification and filtering mechanisms to IMAP4. The requirements for inband and outband server to client notifications are documented in [OMA-ME-RD]. 2. Objectives According to these analyses, there is a need to support: - Mechanisms for event-based (server to client) synchronization: - Defines the relationship between notification mechanisms and the IMAP4 protocol - To minimize the latency observed for email events on the email server to be reflected in the email client. - To avoid unnecessary polling and requests from the e-mail clients: - To reduce the total amount of data to be exchanged between email server and client, e.g. by allowing the email client to select which messages to synchronize and how to synchronize. - To reduce the amount of transactions. - Needs to cope with possible lost or delayed notifications - Support in-band (within IMAP band) and out-band notifications (Exchanged via other servers / enablers). - Specified in ways that are network transport independent but may contain some bindings to particular notification channels (e.g. SMS binary, WAP Push, SIP Notification, ...) - When the email client is connected to the email server, only inband notifications is expected take place - Defines notification payload for inband and outband mechanisms. - Server-side filtering to decide which messages will be accessible by the email client. - Filtering results into the following logical types: - Type A: Messages filtered out and not accessible by the email client (no notification, no header access, no access) - Type B: Messages that are accessible by the mobile e-mail enabler client but no outband notification takes place. Inband notification might however take place if email client is already connected to email server. - Type C: Messages that are accessible by the e-mail client for which notifications (outband or inband) are always sent to the email client. Maes Expires - September 2006 [Page 3] < Lemonade Notifications and Filters> March 2006 - Notions of Filters: - View filters: Filters that determine which email messages are of type B and C or A - Notification filters: Filters that determine which email messages are of type C or B - Event filters: Filters that determines what events are to be notified to the client - Mechanisms to allow the user to update the filters from the email client - Mechanisms to allow configuration and exchange of settings between the client and the server in band or outband: - Server to client: e.g. server ID, account name, policies, … - Client to server: e.g. rules filters vacation notices, notification channel, ... The present document describes how this may be achieved within the scope of LEMONADE Profile [LEMONADEPROFILEBIS]. 3. Notification logical architecture and LEMONADE Profile phase 2 The target logical architectures involving the LEMONADE Profile and notifications are discussed in [LEMONADEPROFILEBIS]. Figure 1 illustrates how notification and filtering can be introduced in the context of LEMONADE profile phase 2. +--------------+_____________ | | +---------| Notification | | | Mechanism | | +----------^---+ |Notif. | |Protocol -------\ +|-+_ | ______| +---\>|NF|----+____ | | | +--+ | +-----+ _____ __v__| IMAP +--+_LEMONADE +---+__ESMTP +--+ | +-----+<-------->|VF| IMAP |DF |<--------|AF| MTA | | MUA |\ ME-2a +--+ Store +-^-+ +--+_____| |_____| \ +-------------+ | +-----+ +-----+--\---------------|-------+ \ |URLAUTH \SUBMIT | \ +----v-----+_____ \ | | +-----+ _____ \ | LEMONADE | ESMTP | | ---->| Submit |--------------->| MTA | ME-2b | Server | |_____| Maes Expires - September 2006 [Page 4] < Lemonade Notifications and Filters> March 2006 |__________| +-----+ +----------+ Figure 1: Filtering mechanism defined in LEMONADE Profile phase 2 architecture. In Figure 1, four categories of filters are defined: - AF: Administrative Filters - Set up by email service provider. AF are typically not configured by the user and set to apply policies content filtering, virus protection, spam filtering etc... - DF: Deposit Filters - Filters that are executed on deposit of new emails. They can be defined as SIEVE filters [SIEVE]. They can include vacation notices. - VF: View Filters - Filters that define which emails are visible to the MUA. View filters can be defined as virtual folders [VFOLDER] as described in later in this document. - NF: Notification Filters - Filters that define for what email server event an outband notification is sent to the client. The filters are manageable from the MUA: - NF and DF: via SIEVE management protocol . [IMAPSIEVE] provides an example of how notification filters (NF) may be expressed in SIEVE. - VF: via VFOLDER as defined in [VFOLDER] 4. Capability Descriptions CAPABILITY can be used to support determination of support of server to client notification. 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 server MUST list what commands it supports. A server can also enumerate individually the other 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 server that implements Server to Client Notification and Filtering. C: a001 CAPABILITY Maes Expires - September 2006 [Page 5] < Lemonade Notifications and Filters> March 2006 S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LPROVISION, LSETPREF, LGETPREF, LNOTIFICATION, LPSEARCH S: a001 OK CAPABILITY completed LPROVISION, LSETPREF and LGETPREF refer to the mechanisms defined in later sections. LPSEARCH declares support for [VFOLDER]. LNOTIFICATION declares support for outband notification filters and filter management as described in this document. 5. Event-based synchronization The addition of Server-to-client notifications transforms the LEMONADE profile into an event-based synchronization protocol. Whenever an event of the type [MSGEVENTS] occurs with the view, a notification can be generated. [MSGEVENTS] provides a list of possible events that could be notified (based on the filter settings). If the MUA is connected to the IMAP server, inband notifications are generated following IDLE [RFC2177]. When the MUA is not connected, the Notification filter generates a notification. The notification filter may be considered as acting on a PUSH repository. All three repositories have the same set of folders. Formally, a repository consists of a set of folders, and each folder has both a name and a set of messages associated with it. The ‘‘complete repository’’ consists of all folders of an end user and all the associated messages for each of those folders. Note UIDs are assume the same in these repositories for a same message. This is illustrated in Figure 2. +----------------+ +---------------+ +------------+ | COMPLETE | | | | | | | (VF) | VIEW | | PUSH | | REPOSITORY | View | REPOSITORY |Notification| REPOSITORY | | all the emails |Filters | emails to be | Filters | important | |in an end user's|========|on the mobile |=========| emails / | | | | | | | events | | email account | |client(VFOLDER)| | | (NF) | +----------------+ +---------------+ | +------------+ | | Maes Expires - September 2006 [Page 6] < Lemonade Notifications and Filters> March 2006 IDLE | | Outband | Notification | | V V Figure 2: Filters and Repositories In inband notification mode, IDLE is exchanged between the MUA and the LEMONADE IMAP server. In outband notification mode, the outband notification may be a message (notification payload) and possibly a set of surrounding exchanges sent with an appropriate format to a particular IP address and port. This may be the address of the MUA. However, in general, it conforms to the interface of a notification server / mechanisms responsible for finalizing the format and sending the notification to the MUA on the client with the appropriate protocol. The following sections provide description of the outband notification payload format and mechanisms to check, set and notification settings. 6. Filters [SIEVE] provides an email filtering language. [VFOLDER] describes how the View Filter (VF) can be implemented and modified from the MUA. [SIEVENOTIFICATION] and [IMAPSIEVE] provides a mechanisms to associate notifications based on the [SIEVE] filter whenever messages are created or changed within a LEMONADE IMAP store. 6.1. Next steps and future work [SIEVE] filters and [IMAPSIEVE] should be extended to support binding to all [MSGEVENTS]. 7. Inband notification payload Inband notification syntax follows the IDLE specifications [RFC2177]. Any inband notification must be considered by the MUA as a wake up call for the MUA to get back to the server. 8. Outband Notification payload Maes Expires - September 2006 [Page 7] < Lemonade Notifications and Filters> March 2006 8.1. Outband Notification Payload in Clear Text The outband notification payload is in general in clear text. Server to Client Notification and Filtering treats the notification as a signal to the client to fetch the information on the server that awaits it. The suggested payload for notifications is that suggested by the OMA, see [OMA-EN]. This notification basically informs the client that some push event has happened on the server, so it must connect to fetch the information. Server to client notifications and filters treats the notificatoon as a MUA wake up event to fetch the information on the server that awaits it. The MUA MAY present other behaviors that exploit additional information provided in the notification. However this is out of scope of the specifications. Wake-up events consists of the following payload: The notification payload is generated by NF and sent to an appropriate messaging interface, appropriately formatted for that interface. The messaging mechanism is then responsible for sending the notification to the MUA. When the client finally connects, the server has opportunity to send other pending events for this client. Example: A new message arrives on the server and this is notified via out-of-band. S: pushes SMS with the following text: The notification payload is sent to an SMSC messaging interface, appropriately formatted for that interface. The SMSC is responsible for sending the SMS to the MUA. C: needs to connect and send any command to get the pending events and act upon them. C: A00 Login joe password S: * SESSION SELECTED S: * FOLDER INBOX Maes Expires - September 2006 [Page 8] < Lemonade Notifications and Filters> March 2006 S: * 100 EXITS S: * 87 EXPUNGE S: * 90 FETCH (FLAGS \Seen) S: A00 OK LOGIN completed C: must now act on the events on the order they are received, meaning, first perform a FETCH to get new message, then expunge message 87 and change flags of message 90. If EXTENDED notification format is supported by the MUA, the following notification may be send instead of the wake-up event as: The notification message is of the form: [, , ,