Internet Draft Gev Decktor Document: draft-ietf-lemonade-notify-s2s-00.txt Comverse Technology Category: Standards Track Expires: January 29, 2005 July 29, 2004 Server To Server Notification Protocol Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with 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 made obsolete 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. Discussion of this and related drafts are on the LEMMONADE list. To subscribe, send the message "subscribe" to lemonade-request@ietf.org. Abstract This memo suggests a set of requirements for the implementation of a protocol in which a messaging system (e.g. email server, voice mail system, etc.) submit 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 service, which may, in turn, generate an end user alert notification. The protocol facilitates 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 service is the entity which is familiar with the end user's notification preferences. Using this protocol, would 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. Decktor Expires January 2005 Page [1] Server To Server Notification Protocol Requirements July 2004 Table of Contents 1. Introduction ................................................ 3 1.1. Scope .................................................. 3 1.2. Basic Operation ........................................ 4 1.3. Terminology ............................................ 4 2. Notification Protocol Contents............... ............... 5 2.1. Informative ............................................ 5 2.2. Subscription ........................................... 6 2.3. Extensibility .......................................... 6 2.4. Exception Handling ..................................... 6 2.5. Retrieval .............................................. 7 3. Notification Protocol Payload Semantics...... ............... 7 3.1. Attributes ............................................. 7 3.1.1. Mandatory Attributes .............................. 7 3.1.2. Additional Attributes ............................. 7 3.2. Events Order ........................................... 8 3.3. Internationalization ................................... 8 4. Operations .................................................. 8 4.1. Scalability ............................................ 8 4.2. Reliability ............................................ 8 4.3. Security ............................................... 9 4.3.1. Threats ........................................... 9 4.3.1.1. Denial of Service (DoS) ...................... 9 4.3.1.2. IP Spoofing ................................. 9 4.3.1.3. Network Snooping ............................. 9 4.3.1.4. Impersonation ................................ 9 4.3.2. Countermeasures ................................... 9 5. References .................................................. 10 6. Acknowledgements ............................................ 10 7. Authors' Addresses .......................................... 10 8. Change Log .................................................. 10 Decktor Expires January 2005 Page [2] Server To Server Notification Protocol Requirements July 2004 1. Introduction 1.1. Scope 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), a Notification service is required to aggregate the information of all the events occurring on the end user's different messaging systems. This memo suggests a set of requirements for the implementation of a protocol in which a messaging system notifies a notification service regarding events occurring in an end user's mailbox. It is important to emphasize, that this protocol does not deal with the communications between the notification service and the end user devices (SMS, WAP Push, MWI, etc.). 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. Decktor Expires January 2005 Page [3] Server To Server Notification Protocol Requirements July 2004 The following figure depicts the notification protocol scope: +--------+ +--------+ New | | | SMS | Message | Email | \ |Gateway | -------> |Server 1| \ _ | | +--------+ \ /| +--------+ ^ \ / | \ / ^ | \ / | +--------+ +--------+ | _|+--------------+ / | | MWI | Read | Voice | | | |/ | |Gateway | Message | Mail |-------->| Notification |------->| | -------> | Server | | ^ _ | Service |\ ^ | +--------+ +--------+ | | /| +--------------- \ | | | |/ \ \| | | / ^ \ ^ \ | |/| | \ | |\| +--------+ / | | \ | | \ +--------+ Mailbox | | /| | | \| | |\ | Wap | Full | Email |/ | | | ^ \ | |_|| Push | -------> |Server 2| | | | | |\| | |Gateway | +--------+ | | | | | \ | +--------+ | | | | | |\| | | | | | | \ | | | | | | |\ | | | | | | |_|+--------+ | | | | | | | | IM | | | | | | | | |Gateway | | | | | | | | | | | | | | | | | +--------+ | | | | | | | Messaging OTHER Notification PROTOCOLS Protocol (not in this document's scope) 1.2. Basic Operation The messaging system notifies a notification service (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 service's implementation. if such data has been received the notification service MAY ignore it. 1.3. Terminology 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 [KEYWORDS]. Decktor Expires January 2005 Page [4] Server To Server Notification Protocol Requirements July 2004 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 Service A system, which aggregates all notification events from multiple Messaging systems to multiple end user destinations. Notification Protocol A protocol that describes how to pass Notification Event data from a Messaging System to a Notification Service. The Messaging System is referred to as the "Source" of the notification and the Notification Service as the "Service". In client/server terms, the Source is the client and the Service is the server. 2. Notification Protocol Contents 2.1. Informative The Notification Protocol MUST be informative enough to allow the Notification Service to: - Identify the end user whose inbox has generated the notification. - Identify the end user that should be informed about the notification event (not necessarily the same as the previous end user). - Decide what kind of actions, the notification service should perform, due to the notification request. - Realize the messaging system's 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. Decktor Expires January 2005 Page [5] Server To Server Notification Protocol Requirements July 2004 In addition, the Notification Protocol SHOULD be informative enough to allow the Notification Service to: - 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). 2.2. Subscription It is RECOMMENDED that the notification protocol would not deal with subscription. This SHOULD be defined in a complimentary protocol, or left to implementers. The rationale behind this relies a few matters: 1. There's no direct necessity of having subscription embedded in the same protocol as notification. it's possible to have it in a complimentary dedicated protocol. 2. This is also the current status of email messaging(no standard subscription protocol). 2.3. Extensibility It is assumed that the notification protocol describes the Mailbox status. Therefore, its data schema MUST be extendable. The notification protocol deals with messaging server-to-server notification. However, in order to allow future extension both in the event types and the initial payload, the protocol must adapt a format that is extendable. For example, if a messaging system needs to send a messageĖs attribute, which isnĖt defined in the protocolĖs definition (x-header, for example), to the notification service, the protocol MUST allow it. 2.4. Exception Handling The notification protocol MUST provide a manner for the notification service to notify the messaging system about the outcome of the notification request (notification status message). The notification service MUST notify the messaging system whenever a protocol violation has occurred. If the request has failed, the data in this notification MUST be coherent enough to allow the messaging system to determine the cause of the failure. The notification service MUST 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. The Messaging system SHOULD parse the notification status message to decide its next actions (e.g. clear the messageĖs content, recompile the messageĖs data, etc.). Decktor Expires January 2005 Page [6] Server To Server Notification Protocol Requirements July 2004 2.5. Retrieval The notification protocol SHOULD allow the source to send URL, as defined in [RFC-URL], referring to the message which has caused the event, to the notification service (and eventually, to the end user). 3. Notification Protocol Payload Semantics 3.1. Attributes The data items, which would be transferred using the notification protocol, are referred to as attributes. The attributes set could be divided into 2 subsets: mandatory attributes and optional attributes. The structure of these attribute sets MAY be complex. This means that different types of notification requests MAY be composed from different sets of attributes. For example: it may be required in the event of a new message deposit to send the message context [RFC-3458] value as well, and not send this attribute in events which describe a mailbox full event. Another example: it SHOULD be possible that when the protocolĖs version is x, there would be a specific set of attributes, and on version x+1 there would be a different set. 3.1.1. Mandatory Attributes The absence of mandatory attributes is a protocol violation. An example for such an attribute would be end Subscriber Identification (only an example “ this name is not committing). In case of a protocol violation, the notification service MUST notify the messaging system. 3.1.2. Additional Attributes Additional attributes are not required, that is their absence does not cause a protocol violation. It is RECOMMENDED that the messaging system would send as many additional attributes as possible to allow maximum accuracy in the notification process. However, a notification service MUST be able to function without any given additional field. Decktor Expires January 2005 Page [7] Server To Server Notification Protocol Requirements July 2004 3.2. Events Order It is assumed that the order of the mailbox events, which have occurred in a given mailbox is important to the notification service. Therefore, it is important that the notification service would have the ability to realize the order of a given group of events. To do so the notification protocol MUST supply manners for the messaging service. 3.3. Internationalization The protocol MUST allow the source to encode its data as unicode. The protocol MUST allow the source to encode its data in any other character set. The protocol MUST supply a manner for specifying the character set and/or the encoding of the notification data. The protocol SHOULD specify a default character set to be used, unless otherwise is specified. 4. Operations 4.1. Scalability The notification protocol SHOULD cause the minimum possible overhead and latency to the messaging system and Notification services which are using it, so that the scale of the systems which use the protocol are not a factor in its implementation. To allow this, the notification protocol MUST assume that: 1. The number of subscribers handled within a single messaging system is unlimited. 2. The number of subscribers handled within a single notification service is unlimited. 3. A single messaging system may work with many notification services. 4. A single notification service may work with many messaging systems. In addition to these issues, it is RECOMMENDED, that the underlying transport level for the notification protocol would support the usage of persistent connections. 4.2. Reliability It is assumed that the data in a notification request is important, and therefore a high level of reliability is needed. In order to support this, the protocol MUST be implemented in such a manner Decktor Expires January 2005 Page [8] Server To Server Notification Protocol Requirements July 2004 that would allow the source receive an acknowledge of the request's receipt. This means that the messaging system is responsible for the notification request until the notification service, has acknowledged its receipt. In addition, the protocol SHOULD provide means for the source to realize the final status of the notification request(failed, succeeded, succeeded partialy etc...) of the notification request. 4.3. Security 4.3.1. Threats Certain threats may affect the participant in the notification event (source, service, end user). The following threats are identified: denial of service, IP spoofing, network snooping and impersonation 4.3.1.1. Denial of Service (DoS) DoS attack might prevent an end user from receiving a notification message by overloading the service. 4.3.1.2. IP Spoofing Since the notification protocolĖs payload MAY hold private end user's data, message data and mailbox data, IP spoofing may cause an attack on the end user's privacy. 4.3.1.3. Network Snooping Packet sniffing on the notification protocolĖs payload may impose a threat on the end user's privacy. 4.3.1.4. Impersonation A source impersonation might cause the service to send notification messages on events that did not occur to the end user. 4.3.2. Countermeasures The notification protocol MUST supply manners to eiliminate all the threats specified in 2.10.1 (e.g. authentication, encryption). Decktor Expires January 2005 Page [9] Server To Server Notification Protocol Requirements July 2004 5. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-URI] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC-URL] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locator(URL)", RFC 1738, December 1994. [RFC-IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. [RFC-3458] E. Burger, E. Candell, C. Eliot, G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003. 6. Acknowledgements The authors wish to acknowledge the following people who helped in the development of this draft: Gal Shapira, Noam Shapira, Ari Erev, Orly Rapaport and Ronit Iaroslavitz. 7. Authors' Addresses Gev Decktor Comverse Technology 29 Habarzel st. Tel-Aviv Israel Phone: +972-3-7655174 Email: gev.decktor@comverse.com 8. Change Log 00 - Initial version, based on draft-decktor-s2s-notif-01.txt Decktor Expires January 2005 Page [10]