Internet DRAFT - draft-maes-lemonade-notifications-filters-how-to
draft-maes-lemonade-notifications-filters-how-to
< Lemonade Notifications and Filters> October 2005
Lemonade
Internet Draft: Lemonade Notifications and S. H. Maes
Filters
Document: draft-maes-lemonade-notifications-
filters-how-to-01
Expires: April 2006 October 2005
Lemonade notifications and filters: how to
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.
Abstract
This document discusses how to provide notification and filtering
mechanisms to IMAP [RFC3501] as part the Lemonade profile
[LEMONADEPROFILE].
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 [RFC2119].
Maes Expires – April 2006 [Page 1]
< Lemonade Notifications and Filters> October 2005
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocol(s) it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for a protocol is said to
be "unconditionally compliant" to that protocol; one that satisfies
all the MUST level requirements but not all the SHOULD level
requirements is said to be "conditionally compliant." When
describing the general syntax, some definitions are omitted as they
are defined in [RFC3501].
Table of Contents
Status of this Memo...............................................1
Abstract..........................................................1
Conventions used in this document.................................1
Table of Contents.................................................2
1. Introduction...................................................2
2. Objectives.....................................................2
3. Capability Descriptions........................................4
4. Event-based synchronization....................................4
5. Filters........................................................4
5.1. Next steps................................................4
6. Checking notification settings.................................4
7. Changing notification settings.................................4
8. Changing filters from the client...............................5
9. Out of scope items for IETF....................................5
Security Considerations...........................................5
References........................................................5
Future Work.......................................................6
Version History...................................................6
Acknowledgments...................................................6
Authors Addresses.................................................7
Intellectual Property Statement...................................7
Full Copyright Statement..........................................7
1.
Introduction
As the work on [LEMONADEPROFILE] progresses, a need has been
identified to provide notification and filtering mechanisms to IMAP4.
The requirements for inband and outband server to client
notifications are documented in [OMA-ME-RD]. Target logical
architecture involving [LEMONADEPROFILE] are discussed in
[LEMONADEPROFILE].
2.
Objectives
Maes Expires – April 2006 [Page 2]
< Lemonade Notifications and Filters> October 2005
According to these analyses, there is a need to support:
- Mechanisms for event-based (server to client) synchronization:
- Defines the relationship between notification mechanisms and the
IMAP4 protocol
- To minimize the latency observed for email events on the
email server to be reflected in the email client.
- To avoid unnecessary polling and requests from the e-mail
clients:
- To reduce the total amount of data to be exchanged between
email server and client, e.g. by allowing the email client
to select which messages to synchronize and how to
synchronize.
- To reduce the amount of transactions.
- Needs to cope with possible lost or delayed notifications
- Support in-band (within IMAP band) and out-band notifications
(Exchanged via other servers / enablers).
- Specified in ways that are network transport independent but
may contain some bindings to particular notification channels
(e.g. SMS binary, WAP Push, SIP Notification, ...)
- When the email client is connected to the email server, only
inband notifications is expected take place
- Defines notification payload for inband and outband mechanisms.
- Server-side filtering to decide which messages will be accessible
by the email client.
- Filtering results into the following logical types:
- Type A: Messages filtered out and not accessible by the email
client (no notification, no header access, no access)
- Type B: Messages that are accessible by the mobile e-mail
enabler client but no outband notification takes place. Inband
notification might however take place if email client is
already connected to email server.
- Type C: Messages that are accessible by the e-mail client for
which notifications (outband or inband) are always sent to the
email client.
- Notions of Filters:
- View filters: Filters that determine which email messages are of
type B and C or A
- Notification filters: Filters that determine which email messages
are of type C or B
- Event filters: Filters that determines what events are to be
notified to the client
- Mechanisms to allow the user to update the filters from the email
client
- Mechanisms to allow configuration and exchange of settings between
the client and the server in band or outband:
- Server to client: e.g. server ID, account name, policies, …
- Client to server: e.g. rules filters vacation notices,
notification channel, ...
Maes Expires – April 2006 [Page 3]
< Lemonade Notifications and Filters> October 2005
The present document describes hos this may be achieved within the
scope of [LEMONADEPROFILE].
3.
Capability Descriptions
[NOTIFICATIONS] defines how CAPABILITY can be used to support
determination of support of server to client notification, filtering
and filter updates..
4.
Event-based synchronization
[NOTIFICATIONS] describes how event-based notification can be
performed. This includes a payload specification for outband
notification based on [OMA-EMN] and possible extensions.
Inband notification is achieved via [IDLE].
[MSGEVENTS] provides a list of possible events that could be notified
(based on the filter settings).
5.
Filters
[SIEVE] provides an email filtering language.
[SIEVENOTIFICATION] provides mechanisms to generate notifications
based on the [SIEVE] filter.
5.1.
Next steps
[SIEVE] filters should be extend to support generating notifications
based on [MSGEVENTS] to support the notions of messages of type A, B
and C and view, notification and event filters described in section
2. The payload should follow [NOTIFICATIONS].
Notifications target the email client through other notification
servers or enablers. The notifications should be sent to the
appropriate server.
6.
Checking notification settings
Mailbox annotations provide additional mechanism for the client to
determine server settings as discussed in [NOTIFICATIONS].
[NOTIFICATIONS] also provides an inband mechanisms (LGETPREFS) to
determine these.
7.
Changing notification settings
Maes Expires – April 2006 [Page 4]
< Lemonade Notifications and Filters> October 2005
[NOTIFICATIONS] provides an inband mechanism to set / change
notification and server settings (LSETPREFS).
8.
Changing filters from the client
[NOTIFICATIONS] provides LFILTER as a way to update inband the
filters from the client.
9.
Out of scope items for IETF
[NOTIFICATIONS] provides specific bindings for SMS (SMS binary, WAP
Push) notifications.
OMA provides ways to perform provisioning via OMA client provisioning
and device management. Other provisioning specifications are
available (e.g. SMS based).
OMA provides enablers to support outband notifications.
OMA XDM may be considered also for outband filter changes.
Security Considerations
Notifications must be secured (when useful information is send) and
integrity should be checkable.
It should be possible to prevent authenticate sender and prevent
Denial of Service attack via notifications.
References
[ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications:
ABNF”, RFC 2234, November 1997.
http://www.ietf.org/rfc/rfc2234
[LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile",
draft-ietf-lemonade-profile-XX.txt, (work in progress).
[MSGEVENTS] Newman, C., "Internet Message Store Events", draft-
newman-lemonade-msgevent-XX.txt, (work in progress).
[NOTIFICATIONS] Maes, S.H. and all, "Server to Client Notifications
and Filtering", draft-maes-lemonade-notifications-server-to-
client-XX.txt, (work in progress).
[OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August
2002. http://www.openmobilealliance.org/tech/docs/EmailNot/OMA-
Push-EMN-V1_0-20020830-C.pdf
Maes Expires – April 2006 [Page 5]
< Lemonade Notifications and Filters> October 2005
[OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document,
(Work in progress). http://www.openmobilealliance.org/
[OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document,
(Work in progress). http://www.openmobilealliance.org/
[P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn
S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP
Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in
progress).
[RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997.
http://www.ietf.org/rfc/rfc2177.
[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
Version 4 rev1", RFC 3501, March 2003.
http://www.ietf.org/rfc/rfc3501
[SIEVE] SIEVE WG, http://www.ietf.org/html.charters/sieve-
charter.html
[SIEVENOTIFICATIONS] Melnikov, A., "Sieve -- An extension for
providing instant notifications", draft-ietf-sieve-notify-XX.txt,
(work in progress)
Future Work
[1] Complete the specification tasks identified in this document.
Version History
Release 01
Added IDLE for inband notifications
Release 00
Initial release
Acknowledgments
The authors want to thank all who have contributed key insight in
notifications and filtering and have authored specifications or
drafts used in this document.
Maes Expires – April 2006 [Page 6]
< Lemonade Notifications and Filters> October 2005
Authors Addresses
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
M/S 4op634
Redwood Shores, CA 94065
USA
Phone: +1-650-607-6296
Email: stephane.maes@oracle.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
Maes Expires – April 2006 [Page 7]
< Lemonade Notifications and Filters> October 2005
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Maes Expires – April 2006 [Page 8]
