Server To Server Notification Protocol Requirements October 2003 Internet Draft Gev Decktor Document: draft-decktor-s2s-notif-00 Comverse Technology Category: Standards Track Expires: May 1, 2004 October 1, 2003 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.) notifies a notification service, about events occurring in an end user's mailbox (e.g. new message has arrived, mailbox is full, etc.). One of the main goals which should be achieved by this, is a notification which would be sent to the end user. Using this protocol, the messaging service can provide the end user a unified method of notifications about events occurring on different messaging systems. Decktor Expires May 2004 Page [1] Server To Server Notification Protocol Requirements October 2003 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 Decktor Expires May 2004 Page [2] Server To Server Notification Protocol Requirements October 2003 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 May 2004 Page [3] Server To Server Notification Protocol Requirements October 2003 The following figure depicts the notification protocol scope: +--------+ +--------+ New | | | | Message | Email | \ | SMS | -------> |Server 1| \ _ | | +--------+ \ /| +--------+ O ^ \ /----------------> t | \ / h | \ / +--------+ e +--------+ | _|+--------------+ / | | r Read | Voice | | | |/ | MWI | Message | Mail |-------->| Notification |------->| | P -------> | Server | | ^ _ | Service |\ | +--------+ r +--------+ | | /| +--------------- \ ---------------> o | |/ | \ t | / ^ | \-----------------> o |/| | |---------\----------------> c +--------+ / | | | \ +--------+ o Mailbox | | /| | | | \ | | l Full | Email |/ | | | v _|| WAP | s -------> |Server 2| | | | +-------------+ | Push | +--------+ | | | | Instant | +--------+ | | | | Messaging | | | | | Application | | | | +-------------+ | | | Notification Protocol 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. The request SHOULD NOT contain data regarding the end user notification destinations. This would be left to the notification service implementation. 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 May 2004 Page [4] Server To Server Notification Protocol Requirements October 2003 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 (e.g. New Message Deposit) - Mailbox Manipulation Task (e.g. Login, Logout, etc.) - Management Task (e.g. Mailbox Full) Decktor Expires May 2004 Page [5] Server To Server Notification Protocol Requirements October 2003 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 a subscription, and this should be defined in a complimentary protocol, or left to implementers. 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 May 2004 Page [6] Server To Server Notification Protocol Requirements October 2003 2.5. Retrieval The notification protocol SHOULD allow the source to send a URI, as defined in [RFC-URI], 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 May 2004 Page [7] Server To Server Notification Protocol Requirements October 2003 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 notification protocol MUST be Unicode compliant, so the source is capable of sending the data in any character set/language or combination of character sets/languages. 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 should be implemented in such a manner Decktor Expires May 2004 Page [8] Server To Server Notification Protocol Requirements October 2003 that would allow the source to work in a ôstore and forwardö concept. This means that the messaging system is responsible for the notification ôrequestö until the notification service, has acknowledged its receipt. 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 May 2004 Page [9] Server To Server Notification Protocol Requirements October 2003 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-IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [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: Noam Shapira, Ari Erev, Morli Bitan and Amir Yefet. 7. Authors' Addresses Gev Decktor Comverse Technology 29 Habarzel st. Tel-Aviv Israel Phone: +972-3-7655174 Email: gev.decktor@comverse.com Decktor Informational - Expires May 2004 Page [10]