Internet Draft: Lemonade Notifications Architecture R. Gellens (Editor)
Document: draft-ietf-lemonade-notifications-10.txt Qualcomm
Expires: January 2009 July 8, 2008
Intended Status: Informational
Lemonade Notifications Architecture
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 (2008). All Rights Reserved.
Abstract
This document discusses how to provide notification and filtering
mechanisms to mail stores to meet Lemonade goals.
This document also discusses the use of server to server
notifications, and how server to server notifications fit into an
architecture which provides server to client notifications.
Gellens [Page 1] Expires January 2009

Internet Draft Lemonade Notifications Architecture July 2008
2. DF: Deposit Filters: Executed on deposit of new mail. Can be
defined as SIEVE filters [SIEVE].
3. VF: View Filters: Define which messages are important to a
client. May be implemented as pseudo-virtual mailboxes [CONTEXT].
Clients may use this to restrict which messages they synchronize.
4. NF: Notification Filters: Determines when out-of-IMAP
("outband") notifications are sent to the client. These filters can
be implemented either in the message store, or in a separate
notifications engine.
Note that when implementing DF or NF using Sieve, the 'enotify'
[SIEVE-NOTIFY] and likely the 'variables' [SIEVE-VARIABLES] Sieve
extensions might be needed.
The filters are manageable by the client as follows:
* NF and DF: When internal to the mail store, these are
typically implemented using Sieve and hence a Sieve management
protocol is used for client modifications. See [MANAGE-SIEVE] for
more information. Per-mailbox notifications might be implemented
using a combination of a primary Sieve script for notifications on
delivery into a mailbox (e.g., FILEINTO) and a per-mailbox Sieve
script such as [IMAP-SIEVE] for transfers into a mailbox. When the
NF is within a notification server, it is out of scope of Lemonade.
* VF: via pseudo-virtual mailboxes as defined in [CONTEXT].
In Figure 1, the NF are shown both as part of the mail store (for
example, using Sieve) and as an external notification server.
Either approach can be used.
Gellens [Page 4] Expires January 2009

Internet Draft Lemonade Notifications Architecture July 2008
3. Event-based synchronization
+----------------+ +---------------+ +------------+
| COMPLETE | (VF) | VIEW | (NF) | PUSH |
| REPOSITORY | View | REPOSITORY |Notification| REPOSITORY |
| |Filters| | Filters | |
| all email | | email to be | | important |
| in the account |=======|synched by the |=====<?>====| email / |
| | | mobile client | | | events |
| | | (CONTEXT) | | | |
+----------------+ +---------------+ | +------------+
| |
IDLE / |
NOTIFY Out-of-IMAP
| Notifications
| |
V V
Figure 2: Filters and Repositories
For in-IMAP ("inband") notifications, the MUA (client) issues IDLE
[IDLE], or the successor extension command NOTIFY [NOTIFY]; the
LEMONADE IMAP server sends notifications as unsolicited responses to
the client.
Out-of-IMAP ("outband") notifications are messages sent to the user
or client not through IMAP. When directed at the user, they are
human-consumable and intended to alert the user. When directed at
the client, they are machine-consumable and may be acted upon by the
receiver in various ways, for example, fetching data from the mail
store or resynchronizing one or more mailboxes, updating internal
state information, and alerting the user.
4. Push Email
A good user experience of "push email" requires that when
"interesting" events occur in the mail store, the client is informed
so that it can connect and resynchronize. The Lemonade Profile
[LEMONADE-PROFILE] contains more information, especially in the
Section titled "External Notifications".
5. Server-to-Server Notifications Rationale
With server to server notifications, a mail system generates event
notifications. These notifications describe mailbox state change
events such as arrival of a new message, mailbox full, and so forth.
Gellens [Page 5] Expires January 2009

Internet Draft Lemonade Notifications Architecture July 2008
See [MSGEVENT] for a list of such events.
These state change notifications are sent to a notification system,
which may generate alerts or notifications for delivery to one or
more clients or the user.
Server to server notifications allow the mail system to generate end
user or client notifications without needing to keep track of
notification settings for users or clients; the notification system
maintains notification preferences for clients and users.
Using server to server notifications, the mail system can provide
the end user with a unified notification experience (the same look
and feel for all messaging systems' accounts, such as email and
voice mail), while allowing smooth integration of additional
messaging systems.
5.1. Notifications Discussion
The POP3 and IMAP4 Internet mail protocols allow mail clients to
access and manipulate electronic mail messages on mail systems. By
definition and scope, these protocols do not provide off-line
methods to notify an end user when the mailbox state changes. Nor
does either protocol define a way to aggregate the status within the
end user's various mailboxes.
The desire for this functionality is obvious. For example, from the
very early days of electronic mail, various notifications mechanisms
have been used, including login shell checks, and simple hacks such
as [BIFF].
To provide an end user with unified notifications and one
centralized message-waiting indication (MWI), notification
mechanisms are needed which aggregate the information of all the
events occurring on the end user's different messaging systems.
Server to server notifications allow the messaging system to send
state change events to the notification system when something
happens in or to an end user's mailbox.
Notification systems can be broadly grouped into three general
architectures: external smart clients, intrinsic notification, and
separate notification mechanisms.
External smart clients are agents independent of the mail system
that periodically check mailbox state (or receive notifications, for
example via IMAP IDLE) and inform the user or the user's mail
client. Many such systems have been used over the years, including
Gellens [Page 6] Expires January 2009

Internet Draft Lemonade Notifications Architecture July 2008
login shells that check the user's mail spool, laptop/desktop tiny
clients that periodically poll the user's mail servers, etc.
Intrinsic notification is any facility within a mail system that
generates notifications, for example the server component of [BIFF],
or, for more modern systems, the recent Sieve extensions for
notifications [SIEVE-NOTIFY].
Separate notification systems decouple the state change event
notification from the end-user or client notification, allowing a
mail system to do the former, and specialized systems (such as those
which handle presence) to be responsible for the latter. This
separation is architecturally cleaner, since the mail system only
needs to support one additional protocol (for communication to the
notification system) instead of multiple notification delivery
protocols, and does not need to keep track of which clients and
which users are interested in which events. It also allows
notifications to be generated for any service, not just electronic
mail. However, it requires a new service (the notification system)
and the mail system needs to support an additional protocol (to
communicate with the notification system).
In addition to any external notification mechanisms, Sieve can be
used for notifications [SIEVE-NOTIFY]. Since many mail systems
already provide Sieve support, it is often a fairly easy and quick
deployment option to provide a useful form of notifications.
5.2. Server to Server Notifications Scope
For the purposes of the Lemonade work, the scope of server to server
notifications is limited to communications between the mail system
and the notification system (the third architectural type described
in Section 5.1). Communication between the notification system and
the end user or devices (which might use SMS, WAP Push, instant
messaging, etc.) is out of scope. Likewise, the scope generally
presumes a security relationship between the mail system and the
notification system. Thus the security relationship then becomes
the responsibility of the notification system. However, the
specifics of security, trust relationships, and related issues
depend on the specifics of both server to server notifications and
notification systems.
Gellens [Page 7] Expires January 2009

Internet Draft Lemonade Notifications Architecture July 2008
The state change event contains data regarding the mailbox event
which has occurred. The state change event describes the change,
but normally does not specify how or if the end user or client is
notified; this allows the end user and client notification
preferences to be maintained only within the notification server.
From the Lemonade viewpoint, out-of-IMAP (outband) notifications are
usually desired only when the client is not connected to the IMAP
server (since inband notifications are used when there is an IMAP
connection). Thus, it is helpful for the mail system to be able to
inform the notification system when the user logs in or out, and
which client is used (when this information is available).
When Sieve is used, the Sieve engine might have access to this
information.
A message is generated by the message store as a result of a state
change event. This message may be delivered to the end user, a
client, or to an external notification server which might deliver an
equivalent message to the user or to a client.
Within the context of Lemonade profile (Figure 1), the event is
filtered by NF. That is, the Notification Filters logically
determine which state change events cause notification to the user
or client.
Notifications allow for a rich end user experience. This might
include conveying mailbox status, new message attributes, etc., to
the user or client independent of the client's connection to the
mail store.
Notifications also allow for different Message Waiting Indicator
(MWI) behaviors (e.g., turn MWI indication off after all the
messages in all the end user's mailboxes have been read, should such
an unlikely thing occur in the real world).
The payload of a notification might include a URL referring to the
message which caused the event, possibly using URLAUTH [URLAUTH].
As state change events occur in the mail store, they are filtered,
which is to say matched against client or user preferences. As a
result, a notification may or may not be generated for delivery to
the user or client.
In the most general case, the mail system sends bulk state change
events to an external notification server, and it is the
notification server that filters the events by matching against the
user's or client's preferences.
Gellens [Page 9] Expires January 2009

Internet Draft Lemonade Notifications Architecture July 2008
In the most mail-specific case, the mail system performs the
filtering itself, for example using Sieve.
5.4. Event order
For Lemonade profile, the event order is generally not important.
By including information such as the modification sequence
identifier (called a modseq or mod-sequence) [CONDSTORE] in
notifications, the receiving client can quickly and easily determine
if it has already processed the triggering event (for example, if a
notification arrives out of order, or if the client has
resynchronized).
For generic server to server notifications, the order is likely to
matter and the mail system needs to provide notifications to the
notification system in the order that they occur.
5.5. Reliability
For the Lemonade profile, lost or delayed notifications to the
client are tolerated. A client can resynchronize its state
(including that reported by any missing events) when it next
connects to the server.
For generic server to server notifications, it is assumed that the
data in a state change event is important, and therefore a high
level of reliability is needed between the mail system and any
external notification systems.
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.
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.
Protocols which manipulate filters need mechanisms to protect
against modification by as well as disclosure to unauthorized
entities. For example, a malicious entity might try to delete
notifications the user wants, or try to flood the target device with
notifications to incur usage charges, or prevent normal use. In
addition, the filters themselves might contain sensitive information
Gellens [Page 10] Expires January 2009

Internet Draft Lemonade Notifications Architecture July 2008
o 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)
o Added notification protocol details and reference
version -02:
o LPROVISION/LGETPREFS/LSETPREFS removed in favor of mailbox
annotations
o Updated inband notification section to include discussion of
CLEARIDLE and MSGEVENTS
o EMN payload clarified for both wakeup and extended formats.
o Some reference clean-up
o Add server to server notifications based on the expired draft
draft-ietf-lemonade-notify-s2s-00.
version -01:
o Move SMS / WAP examples to an informative appendix.
o Restrict the exchange of keys via LPROVISION to secure
exchanges.
o Differentiate ANNOTATE from LPROVISION on that basis.
versin -00:
o 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
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.
Gellens [Page 16] Expires January 2009

Internet Draft Lemonade Notifications Architecture July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gellens [Page 17] Expires January 2009