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]