< Lemonade Notifications and Filters> October 2005 Lemonade Internet Draft: Lemonade Notifications and S. H. Maes Filters Document: draft-maes-lemonade-notifications- filters-how-to-01 Expires: April 2006 October 2005 Lemonade notifications and filters: how to 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. Abstract This document discusses how to provide notification and filtering mechanisms to IMAP [RFC3501] as part the Lemonade profile [LEMONADEPROFILE]. 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]. Maes Expires – April 2006 [Page 1]  < Lemonade Notifications and Filters> October 2005 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 2. Objectives.....................................................2 3. Capability Descriptions........................................4 4. Event-based synchronization....................................4 5. Filters........................................................4 5.1. Next steps................................................4 6. Checking notification settings.................................4 7. Changing notification settings.................................4 8. Changing filters from the client...............................5 9. Out of scope items for IETF....................................5 Security Considerations...........................................5 References........................................................5 Future Work.......................................................6 Version History...................................................6 Acknowledgments...................................................6 Authors Addresses.................................................7 Intellectual Property Statement...................................7 Full Copyright Statement..........................................7 1. Introduction As the work on [LEMONADEPROFILE] 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]. Target logical architecture involving [LEMONADEPROFILE] are discussed in [LEMONADEPROFILE]. 2. Objectives Maes Expires – April 2006 [Page 2]  < Lemonade Notifications and Filters> October 2005 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. - 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, ... Maes Expires – April 2006 [Page 3]  < Lemonade Notifications and Filters> October 2005 The present document describes hos this may be achieved within the scope of [LEMONADEPROFILE]. 3. Capability Descriptions [NOTIFICATIONS] defines how CAPABILITY can be used to support determination of support of server to client notification, filtering and filter updates.. 4. Event-based synchronization [NOTIFICATIONS] describes how event-based notification can be performed. This includes a payload specification for outband notification based on [OMA-EMN] and possible extensions. Inband notification is achieved via [IDLE]. [MSGEVENTS] provides a list of possible events that could be notified (based on the filter settings). 5. Filters [SIEVE] provides an email filtering language. [SIEVENOTIFICATION] provides mechanisms to generate notifications based on the [SIEVE] filter. 5.1. Next steps [SIEVE] filters should be extend to support generating notifications based on [MSGEVENTS] to support the notions of messages of type A, B and C and view, notification and event filters described in section 2. The payload should follow [NOTIFICATIONS]. Notifications target the email client through other notification servers or enablers. The notifications should be sent to the appropriate server. 6. Checking notification settings Mailbox annotations provide additional mechanism for the client to determine server settings as discussed in [NOTIFICATIONS]. [NOTIFICATIONS] also provides an inband mechanisms (LGETPREFS) to determine these. 7. Changing notification settings  Maes Expires – April 2006 [Page 4] < Lemonade Notifications and Filters> October 2005 [NOTIFICATIONS] provides an inband mechanism to set / change notification and server settings (LSETPREFS). 8. Changing filters from the client [NOTIFICATIONS] provides LFILTER as a way to update inband the filters from the client. 9. Out of scope items for IETF [NOTIFICATIONS] provides specific bindings for SMS (SMS binary, WAP Push) notifications. OMA provides ways to perform provisioning via OMA client provisioning and device management. Other provisioning specifications are available (e.g. SMS based). OMA provides enablers to support outband notifications. OMA XDM may be considered also for outband filter changes. Security Considerations Notifications must be secured (when useful information is send) and integrity should be checkable. It should be possible to prevent authenticate sender and prevent Denial of Service attack via notifications. References [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, November 1997. http://www.ietf.org/rfc/rfc2234 [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", draft-ietf-lemonade-profile-XX.txt, (work in progress). [MSGEVENTS] Newman, C., "Internet Message Store Events", draft- newman-lemonade-msgevent-XX.txt, (work in progress).  [NOTIFICATIONS] Maes, S.H. and all, "Server to Client Notifications and Filtering", draft-maes-lemonade-notifications-server-to- client-XX.txt, (work in progress). [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 Maes Expires – April 2006 [Page 5] < Lemonade Notifications and Filters> October 2005 [OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document, (Work in progress). http://www.openmobilealliance.org/ [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, (Work in progress). http://www.openmobilealliance.org/ [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997. http://www.ietf.org/rfc/rfc2177. [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 [SIEVE] SIEVE WG, http://www.ietf.org/html.charters/sieve- charter.html [SIEVENOTIFICATIONS] Melnikov, A., "Sieve -- An extension for providing instant notifications", draft-ietf-sieve-notify-XX.txt, (work in progress) Future Work [1] Complete the specification tasks identified in this document. Version History  Release 01 Added IDLE for inband notifications Release 00 Initial release Acknowledgments The authors want to thank all who have contributed key insight in notifications and filtering and have authored specifications or drafts used in this document. Maes Expires – April 2006 [Page 6] < Lemonade Notifications and Filters> October 2005 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 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 implementers 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 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 (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE Maes Expires – April 2006 [Page 7] < Lemonade Notifications and Filters> October 2005 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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.  Maes Expires – April 2006 [Page 8]