Internet Draft: Lemonade Notifications and Filters R. Gellens (Editor) Document: draft-ietf-lemonade-notifications-05.txt Qualcomm Expires: May 2008 November 17, 2007 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 IETF Trust (2007). All Rights Reserved. Abstract This document discusses how to provide notification and filtering mechanisms to IMAP as part the Lemonade profile. This document also discusses the use of Lemonade notifications to implement server to server notifications. Gellens [Page 1] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 Table of Contents 1. Conventions Used in this Document . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 3. Notification logical architecture and LEMONADE Profile bis 3 4. Event-based synchronization . . . . . . . . . . . . . . . 5 5. Server to server notifications considerations . . . . . . . 6 5.1. Scope of server to server notifications . . . . . . . 6 5.2. Basic Operation . . . . . . . . . . . . . . . . . . . . 8 5.3. Server to server terminology . . . . . . . . . . . . . 9 5.4. Notification payloads . . . . . . . . . . . . . . . . . 9 5.5. Server to server notification protocol details . . . . 10 5.5.1. Generic case . . . . . . . . . . . . . . . . . . . 10 5.5.2. Abstracted notification protocol . . . . . . . . . 11 5.5.3. Exception Handling . . . . . . . . . . . . . . . . 11 5.6. Server to server complementary information . . . . . . 12 5.7. Event orders . . . . . . . . . . . . . . . . . . . . . 12 5.8. Reliability . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 8. Normative and Informative References . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 15 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A: Changes from Previous Versions . . . . . . . . . 16 Intellectual Property Statement . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 1. 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]. Gellens [Page 2] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 2. 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]. 3. Notification logical architecture and LEMONADE Profile bis The target logical architectures involving the LEMONADE Profile and notifications are discussed in [LEMONADEPROFILEBIS]. Gellens [Page 3] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 Figure 1 illustrates how notification and filtering can be introduced in the context of LEMONADE profile bis. +--------------+ | | +---------| 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 | | | | | +-----+ +----------+ Figure 1: Filtering mechanism defined in LEMONADE Profile bis 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: Gellens [Page 4] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 # 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. Event-based synchronization +----------------+ +---------------+ +------------+ | 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) | +----------------+ +---------------+ | +------------+ | | IDLE | | Outband | Notification | | V V Figure 2: Filters and Repositories In inband notification mode, the MUA issues IDLE, or the successor extension command NOTIFY, and notifications are sent as unsolicited responses to the MUA from the LEMONADE IMAP server. In outband notification mode, the outband notification may be an message (notification payload) and possibly a set of surrounding exchanges, sent with an appropriate format to a particular address (such as an 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. Gellens [Page 5] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 5. Server to server notifications considerations The following sections focus on considerations and usage of the Lemonade notifications for server to server notifications With server to server notifications, a messaging system (e.g. email server, voice mail system, etc.) submits alerts, which describe potential notification events, regarding an end user mailbox status change (e.g. new message has arrived, mailbox is full, etc.). These alerts are sent to a notification mechanisms, which may, in turn, generate an end user alert notification. Server to server notifications facilitate a solution where the messaging system initiates an end user notification, while allowing the messaging system, not to be familiar with the end user's notification preferences. The notification mechanisms are the entities which is familiar with the end user's notification preferences. Using server to server notifications, allow the messaging system to provide the end user, a unified notification experience (the same look and feel for all messaging systems' accounts), while allowing smooth integration of additional Messaging systems. 5.1. Scope of server to server notifications The suite of Internet mail protocols (POP3, IMAP4) allows different mail clients to access and manipulate electronic mail messages on a messaging system. These protocols, however, do not provide off-line methods by which an end user can be notified upon changes in the mailbox status. Further, none of the mentioned protocols defines a way to aggregate the status within the end user's various mailboxes. To provide an end user with the ability of unified Notification and one centralized message-waiting indication (MWI), notification mechanisms are required to aggregate the information of all the events occurring on the end user's different messaging systems. With server to server notifications, a messaging system notifies the notification mechanisms regarding events occurring in an end user's mailbox. It is important to emphasize, that server to server notifications do not deal with the communications between the notification mechanisms and the end user devices (SMS, WAP Push, MWI, etc.). Gellens [Page 6] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 For example, when an email message is deposited in an email server, the email server sends a "new message" notification to the notification service, which then notifies the end user by a Short Text Message (SMS). This process can be extended to include other mailbox events that are important to the end user, such as "mailbox full" and "message rejected" or any other mailbox status change. Each notification should include additional information that is available to the end user such as the mailbox status, message attributes, etc. Gellens [Page 7] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 The figure 3 depicts the server to server notification scope: +--------+ +--------+ New | | | SMS | Message | Email | \ |Gateway | -------> |Server 1| \ _ | | +--------+ \ /| +--------+ ^ \ / | \ / ^ | \ +--------------+ / | +--------+ +--------+ | _|+-------------|+ / | | MWI | Read | Voice | | || |/ | |Gateway | Message | Mail |-------->| Notification |------->| | -------> | Server | | ^ _ +| Mechanisms |\ ^ | +--------+ +--------+ | | /| +--------------- \ | | | |/ \ \| | | / ^ \ ^ \ | |/| | \ | |\| +--------+ / | | \ | | \ +--------+ Mailbox | | /| | | \| | |\ | Wap | Full | Email |/ | | | ^ \ | |_|| Push | -------> |Server 2| | | | | |\| | |Gateway | +--------+ | | | | | \ | +--------+ | | | | | |\| | | | | | | \ | | | | | | |\ | | | | | | |_|+--------+ | | | | | | | | IM | | | | | | | | |Gateway | | | | | | | | | | | | | | | | | +--------+ | | | | | | | Server to OTHER Server PROTOCOLS Notifications Figure 3: Scope of server to server notifications The notification mechanisms can either provide an abstract notification mechanism able to convert notifications to an appropriate channel or expose the northbound interface (application interface) exposed by a specific notification channel. In the latter case it may just be a logical concept and the sender of notifications may directly address the appropriate notification channels. All the options are viable. Gellens [Page 8] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 5.2. Basic Operation The messaging system notifies the notification mechanisms (which in turn MAY notify an end user) about events that occurred in the end user's mailbox. Each such notification, referring to a single mailbox event is referred to as a notification request. The notification request SHOULD contain data regarding the mailbox event which has occurred. It's RECOMMENDED that the request would not contain data regarding the end user notification destinations. This would be left to the notification mechanisms' implementation. If such data has been received the notification mechanisms MAY ignore it. 5.3. Server to server terminology This specification uses the following terms: Message Waiting Indication (MWI): A mechanism that indicates to the end user that a message is waiting in a Messaging System Examples for such action are: SMS message, WAP push message, Instant messaging notification, telephony stutter tone, etc. MWI states may be ON or OFF. Notification Event: An event that may result in a notification to the end user or may change the MWI state (ON or OFF) Messaging System: A system that maintains a set of one or more mailboxes for end user's messages, for example: email servers, voicemail systems, etc. Notification Mechanisms: A system, which aggregates all notification events from multiple Messaging systems to multiple end user destinations. 5.4. Notification payloads Gellens [Page 9] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 The cases of Figure 1 and Figure 3 are very similar. In both cases a message must be generated by the message store as result of a message event. This message is communicated to the messaging mechanisms. Within the context of Lemonade profile (Figure 1), the event is filtered by NF and the payload of the notification is defined in section section. In more generic cases, the server to server notification payload can be any message. Certain may be defined to: # Realize the messaging mecanisms' task which has caused the notification event. The task may be related to one of the following: * New message Task - New Message Deposit * Mailbox Manipulation Task (e.g. Login, Logout, etc.) - Login to mailbox - Logout from mailbox - Read message - Delete Message - Purge Message * Management Task (e.g. Mailbox Full) - Mailbox full - Mailbox full cancellation The task's types list, as defined above, SHOULD be extendable. # Provide a rich experience to the end user of the notification, without the need to actually retrieve the message. This MAY include mailbox status, message attributes, etc. # Practice different MWI behaviors (e.g. turn MWI indication off after all the messages in all the end user's mailboxes have been read). # URL, as defined in [RFC-URL] or [URLAUTH], referring to the message which has caused the event, to the notification mecanisms (and eventually, to the end user). 5.5. Server to server notification protocol details 5.5.1. Generic case Within the more general case of server to server notification, the payload may be an arbitrary text or binary message. Gellens [Page 10] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 In both cases the interaction model is defined as: 1 An event takes place in the message store 2 The event is filtered. As a result it may be hidden or result into a notification. 3 The notification is a message in a particular payload that is prepared for the target notification mechanisms. 4 The payload is complemented with the necessary information to tell the notification mechanism how and where to send the notification. 5 The complemented payload is then formatted as required by the target notification mechanisms (i.e., the right format on the right port to be sent to the right address, possibly with an appropriate protocol binding, e.g. HTTP PUT) plus the information about where / how to send the notification. This last step is imposed by the notification mechanisms and must be known by the notification generating filter. Different interfaces and bindings may be used depending on the notification channel. 5.5.2. Abstracted notification protocol When a mechanism is provided to abstractly notify a notification mechanism that is then responsible for notifying via the appropriate channel, the notification protocol MUST follow [NOTIFICATIONPROTOCOL]. 5.5.3. Exception Handling It is assumed that the interface exposed by the notification mechanisms can notify the messaging system about the outcome of the notification request (notification status message). The notification mechanisms SHOULD notify the messaging system whenever a problem has occurred. If the request has failed, the response, when available, SHOULD be coherent enough to allow the messaging system to determine the cause of the failure. The notification mechanisms SHOULD make a distinction between events in which the content of the request has caused an error (request errors), and cases in which a non-source-related reason has caused the error. Gellens [Page 11] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 The Messaging system SHOULD parse the notification status message, when available, to decide its next actions (e.g. clear the message's content, recompile the message data, etc.). 5.6. Server to server complementary information The server to server complementary information MUST include: * Identify the end user whose inbox has generated the notification. * Identify the end user or end target addresses or identifiers that should be informed about the notification event (not necessarily the same as the previous end user). * Decide what kind of actions, the notification mechanisms should perform, due to the notification request. 5.7. Event orders For lemonade profile bis, the event order is not important. For generic server to server notifications, the order may matter and the messaging system must provide the notifications in the order that they are generated by mailbox events. 5.8. Reliability For Lemonade profile bis, lost or delayed notifications of the MUA are not critical. A client can recover all missing events next time it connects to the server and the server MUST buffer the notifications and make them available to the MUA when it comes back to the server. For generic server to server notifications, it is assumed that the data in a notification request is important, and therefore a high level of reliability is needed. In such cases it MUST be possible to provide acknowledgment by the target to the messaging system or to repeat notification until such an acknowledgement is provided if supported by the notification channel. Alternatively it must be possible for the messaging system to request such repeats. 6. Security Considerations Notification content (payload) needs to be protected against eavesdropping and alteration when it contains specific information from messages, such as the sender. Gellens [Page 12] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 Even when the content is trivial and does not contain privacy-sensitive information, guarding against denial of service attacks may require authentication or verification of the notification sender. 7. IANA Considerations None. 8. Normative and Informative References [[ editor's note: split into two sections, update references ]] [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. http://www.ietf.org/rfc/rfc2234 [ANNOTATEMORE] Daboo, C., "IMAP ANNOTATEMORE Extension", work in progress, draft-daboo-imap-annotatemore-xx, (work in progress). [GSM03.40] GSM 03.40 v7.4.0 Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS). ETSI 2000 [IMAP-DISC] Melnikov, A. "Synchronization operations for disconnected IMAP4 clients", draft-melnikov-imap-disc-06.txt, October 2004. [IMAP-EVENTS] Melnikov, A. " Lemonade Inband Notifications", draft-melnikov-lemonade-imap-events-00.txt, June 17, 2006 [IMAPSIEVE] Leiba, B., "Support for Sieve in Internet Message Access Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-0x (work in progress). [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", draft-ietf-lemonade-profile-XX.txt, (work in progress). [LEMONADEPROFILEBIS] Maes, S.H., Melnikov A. and D. Cridland, " LEMONADE profile bis", draft-ietf-lemonade-profile-bis-xx.txt, (work in progress). [MANAGESIEVE] Martin, T. and A. Melnikov, "A Protocol for Remotely Managing Sieve Scripts", draft-martin-managesieve-xx.txt, (work in progress). Gellens [Page 13] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 [MSGEVENTS] Newman, C., "Internet Message Store Events", draft- newman-lemonade-msgevent-xx.txt, (work in progress). [NOTIFICATIONPROTOCOL] Maes, S.H., " Lemonade Notification protocol ", draft-ietf-lemonade-notification-protocol-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 [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). [RECONNECT] A. Melnikov, C. Wilson, "IMAP4 Extensions for Quick Reconnect", draft-ietf-lemonade-reconnect-06.txt, May 2006 [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) [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth- XX.txt, (work in progress). [VFOLDER] Maes, S. and et Al., "Persistent Search Extensions and Virtual Folder to the IMAP Protocol", draft-maes-lemonade-vfolder- 0x, (work in progress). Gellens [Page 14] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 [WAPWDP] Wireless Datagram Protocol, Version 14-Jun-2001, Wireless Application Protocol WAP-259-WDP- 20010614-aWAP (WDP) 9. Acknowledgments The original, and significantly longer, version of this document was authored by Stephane H. Maes and Ray Cromwell of Oracle Corporation. 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, including the original work on P-IMAP [P-IMAP]. The authors want to thank the authors of the original work on Server To Server Notification Protocol Requirements (draft-ietf-lemonade- notify-s2s-00) whose material has been incorporated in the present document, in particular, Gev Decktor. 10. Author's Address Editor: Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 randy@qualcomm.com Authors: 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 Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Gellens [Page 15] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 Appendix A: Changes from Previous Versions THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. version -05: * Significant deletion of sections, per www1.ietf.org/mail-archive/web/lemonade/current/msg03936.html version -04: * Update dates, slight reformatting, add editor's note for References version -03: * Updated examples to use new METADATA syntax * Drop CLEARIDLE and reference A. Melnikov's [IMAP-EVENTS] * XEMN notification format extended to with event and view attributes * View filter is a work in progress. Several proposals are being discussed, so the draft has been revised to try and capture high level requirements (e.g. out of band notifications must be able to identify which view an event occurred for) * Added notification protocol details and reference version -02: * LPROVISION/LGETPREFS/LSETPREFS removed in favor of mailbox annotations * Updated inband notification section to include discussion of [CLEARIDLE] and [MSGEVENTS] * EMN payload clarified for both wakeup and extended formats. * Some reference clean-up * Add server to server notifications based on the expired draft draft-ietf-lemonade-notify-s2s-00. version -01: * Move SMS / WAP examples to an informative appendix. * Restrict the exchange of keys via LPROVISION to secure exchanges. * Differentiate ANNOTATE from LPROVISION on that basis. versin -00: * Initial release Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such Gellens [Page 16] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Gellens [Page 17] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Gellens [Page 18] Expires May 2008