Internet DRAFT - draft-ietf-lemonade-notify-s2s
draft-ietf-lemonade-notify-s2s
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]
