Internet Draft: Lemonade Notifications and Filters R. Gellens (Editor)
Document: draft-ietf-lemonade-notifications-05.txt Qualcomm
Expires: May 2008 November 17, 2007
Lemonade Notifications and Filters
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 (2007). All Rights Reserved.
Abstract
This document discusses how to provide notification and filtering
mechanisms to IMAP as part the Lemonade profile.
This document also discusses the use of Lemonade notifications to
implement server to server notifications.
Gellens [Page 1] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
3. Notification logical architecture and LEMONADE Profile bis 3
4. Event-based synchronization . . . . . . . . . . . . . . . 5
5. Server to server notifications considerations . . . . . . . 6
5.1. Scope of server to server notifications . . . . . . . 6
5.2. Basic Operation . . . . . . . . . . . . . . . . . . . . 8
5.3. Server to server terminology . . . . . . . . . . . . . 9
5.4. Notification payloads . . . . . . . . . . . . . . . . . 9
5.5. Server to server notification protocol details . . . . 10
5.5.1. Generic case . . . . . . . . . . . . . . . . . . . 10
5.5.2. Abstracted notification protocol . . . . . . . . . 11
5.5.3. Exception Handling . . . . . . . . . . . . . . . . 11
5.6. Server to server complementary information . . . . . . 12
5.7. Event orders . . . . . . . . . . . . . . . . . . . . . 12
5.8. Reliability . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
8. Normative and Informative References . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 15
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A: Changes from Previous Versions . . . . . . . . . 16
Intellectual Property Statement . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
1. 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].
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].
Gellens [Page 2] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
2. Introduction
As the work on LEMONADE Profile ([LEMONADEPROFILE] and
[LEMONADEPROFILEBIS]) 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].
3. Notification logical architecture and LEMONADE Profile bis
The target logical architectures involving the LEMONADE Profile and
notifications are discussed in [LEMONADEPROFILEBIS].
Gellens [Page 3] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
Figure 1 illustrates how notification and filtering can be
introduced in the context of LEMONADE profile bis.
+--------------+
| |
+---------| Notification |
| | Mechanism |
| +----------^---+
|Notif. |
|Protocol -------\ +|-+_
| ______| +---\>|NF|----+
| | | +--+ | +-----+
v | IMAP +--+_LEMONADE +---+ ESMTP +--+ |
+-----+<-------->|VF| IMAP |DF |<--------|AF| MTA |
| MUA |\ ME-2a +--+ Store +-^-+ +--+ |
| | \ +-------------+ | +-----+
+-----+--\---------------|-------+
\ |URLAUTH
\SUBMIT |
\ +----v-----+
\ | | +-----+
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
ME-2b | Server | | |
| | +-----+
+----------+
Figure 1: Filtering mechanism defined in LEMONADE Profile bis
architecture.
In Figure 1, four categories of filters are defined:
# AF: Administrative Filters - Set up by email service provider.
AF are typically not configured by the user and set to apply
policies content filtering, virus protection, spam filtering etc...
# DF: Deposit Filters - Filters that are executed on deposit of
new emails. They can be defined as SIEVE filters [SIEVE]. They
can include vacation notices.
# VF: View Filters - Filters that define which emails are visible
to the MUA. View filters can be defined as virtual folders
[VFOLDER] as described in later in this document.
# NF: Notification Filters - Filters that define for what email
server event an outband notification is sent to the client.
The filters are manageable from the MUA:
Gellens [Page 4] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
# NF and DF: via SIEVE management protocol <Editor's note: Still
to be defined>. [IMAPSIEVE] provides an example of how notification
filters (NF) may be expressed in SIEVE.
# VF: via VFOLDER as defined in [VFOLDER]
4. Event-based synchronization
+----------------+ +---------------+ +------------+
| COMPLETE | | | | |
| | (VF) | VIEW | | PUSH |
| REPOSITORY | View | REPOSITORY |Notification| REPOSITORY |
| all the emails |Filters | emails to be | Filters | important |
|in an end user's|========|on the mobile |=====<?>====| emails / |
| | | | | | events |
| email account | |client(VFOLDER)| | | (NF) |
+----------------+ +---------------+ | +------------+
| |
IDLE |
| Outband
| Notification
| |
V V
Figure 2: Filters and Repositories
In inband notification mode, the MUA issues IDLE, or the successor
extension command NOTIFY, and notifications are sent as unsolicited
responses to the MUA from the LEMONADE IMAP server.
In outband notification mode, the outband notification may be an
message (notification payload) and possibly a set of surrounding
exchanges, sent with an appropriate format to a particular address
(such as an IP address and port). This may be the address of the
MUA. However, in general, it conforms to the interface of a
notification server / mechanisms responsible for finalizing the
format and sending the notification to the MUA on the client with
the appropriate protocol.
The following sections provide description of the outband
notification payload format and mechanisms to check, set and
notification settings.
Gellens [Page 5] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
5. Server to server notifications considerations
The following sections focus on considerations and usage of the
Lemonade notifications for server to server notifications
With server to server notifications, a messaging system (e.g. email
server, voice mail system, etc.) submits 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 mechanisms, which may, in
turn, generate an end user alert notification.
Server to server notifications facilitate 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 mechanisms are the entities which is familiar with
the end user's notification preferences.
Using server to server notifications, 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.
5.1. Scope of server to server notifications
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), notification
mechanisms are required to aggregate the information of all the
events occurring on the end user's different messaging systems.
With server to server notifications, a messaging system notifies the
notification mechanisms regarding events occurring in an end user's
mailbox. It is important to emphasize, that server to server
notifications do not deal with the communications between the
notification mechanisms and the end user devices (SMS, WAP Push,
MWI, etc.).
Gellens [Page 6] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
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.
Gellens [Page 7] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
The figure 3 depicts the server to server notification scope:
+--------+ +--------+
New | | | SMS |
Message | Email | \ |Gateway |
-------> |Server 1| \ _ | |
+--------+ \ /| +--------+
^ \ /
| \ / ^
| \ +--------------+ / | +--------+
+--------+ | _|+-------------|+ / | | MWI |
Read | Voice | | || |/ | |Gateway |
Message | Mail |-------->| Notification |------->| |
-------> | Server | | ^ _ +| Mechanisms |\ ^ | +--------+
+--------+ | | /| +--------------- \ | |
| |/ \ \| |
| / ^ \ ^ \ |
|/| | \ | |\|
+--------+ / | | \ | | \ +--------+
Mailbox | | /| | | \| | |\ | Wap |
Full | Email |/ | | | ^ \ | |_|| Push |
-------> |Server 2| | | | | |\| | |Gateway |
+--------+ | | | | | \ | +--------+
| | | | | |\|
| | | | | | \
| | | | | | |\
| | | | | | |_|+--------+
| | | | | | | | IM |
| | | | | | | |Gateway |
| | | | | | | | |
| | | | | | | +--------+
| | | | | | |
Server to OTHER
Server PROTOCOLS
Notifications
Figure 3: Scope of server to server notifications
The notification mechanisms can either provide an abstract
notification mechanism able to convert notifications to an
appropriate channel or expose the northbound interface (application
interface) exposed by a specific notification channel. In the
latter case it may just be a logical concept and the sender of
notifications may directly address the appropriate notification
channels. All the options are viable.
Gellens [Page 8] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
5.2. Basic Operation
The messaging system notifies the notification mechanisms (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 mechanisms' implementation.
If such data has been received the notification mechanisms MAY
ignore it.
5.3. Server to server terminology
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 Mechanisms:
A system, which aggregates all notification events from multiple
Messaging systems to multiple end user destinations.
5.4. Notification payloads
Gellens [Page 9] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
The cases of Figure 1 and Figure 3 are very similar.
In both cases a message must be generated by the message store as
result of a message event. This message is communicated to the
messaging mechanisms.
Within the context of Lemonade profile (Figure 1), the event is
filtered by NF and the payload of the notification is defined in
section section.
In more generic cases, the server to server notification payload can
be any message. Certain may be defined to:
# Realize the messaging mecanisms' 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.
# 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).
# URL, as defined in [RFC-URL] or [URLAUTH], referring to the
message which has caused the event, to the notification
mecanisms (and eventually, to the end user).
5.5. Server to server notification protocol details
5.5.1. Generic case
Within the more general case of server to server notification, the
payload may be an arbitrary text or binary message.
Gellens [Page 10] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
In both cases the interaction model is defined as:
1 An event takes place in the message store
2 The event is filtered. As a result it may be hidden or result
into a notification.
3 The notification is a message in a particular payload that is
prepared for the target notification mechanisms.
4 The payload is complemented with the necessary information to
tell the notification mechanism how and where to send the
notification.
5 The complemented payload is then formatted as required by the
target notification mechanisms (i.e., the right format on the
right port to be sent to the right address, possibly with an
appropriate protocol binding, e.g. HTTP PUT) plus the
information about where / how to send the notification. This
last step is imposed by the notification mechanisms and must be
known by the notification generating filter.
Different interfaces and bindings may be used depending on the
notification channel.
5.5.2. Abstracted notification protocol
When a mechanism is provided to abstractly notify a notification
mechanism that is then responsible for notifying via the appropriate
channel, the notification protocol MUST follow
[NOTIFICATIONPROTOCOL].
5.5.3. Exception Handling
It is assumed that the interface exposed by the notification
mechanisms can notify the messaging system about the outcome of the
notification request (notification status message). The
notification mechanisms SHOULD notify the messaging system whenever
a problem has occurred.
If the request has failed, the response, when available, SHOULD be
coherent enough to allow the messaging system to determine the cause
of the failure.
The notification mechanisms SHOULD 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.
Gellens [Page 11] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
The Messaging system SHOULD parse the notification status message,
when available, to decide its next actions (e.g. clear the message's
content, recompile the message data, etc.).
5.6. Server to server complementary information
The server to server complementary information MUST include:
* Identify the end user whose inbox has generated the
notification.
* Identify the end user or end target addresses or identifiers
that should be informed about the notification event (not
necessarily the same as the previous end user).
* Decide what kind of actions, the notification mechanisms should
perform, due to the notification request.
5.7. Event orders
For lemonade profile bis, the event order is not important.
For generic server to server notifications, the order may matter and
the messaging system must provide the notifications in the order
that they are generated by mailbox events.
5.8. Reliability
For Lemonade profile bis, lost or delayed notifications of the MUA
are not critical. A client can recover all missing events next time
it connects to the server and the server MUST buffer the
notifications and make them available to the MUA when it comes back
to the server.
For generic server to server notifications, it is assumed that the
data in a notification request is important, and therefore a high
level of reliability is needed. In such cases it MUST be possible
to provide acknowledgment by the target to the messaging system or
to repeat notification until such an acknowledgement is provided if
supported by the notification channel. Alternatively it must be
possible for the messaging system to request such repeats.
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.
Gellens [Page 12] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
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.
7. IANA Considerations
None.
8. Normative and Informative References
[[ editor's note: split into two sections, update references ]]
[ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997. http://www.ietf.org/rfc/rfc2234
[ANNOTATEMORE] Daboo, C., "IMAP ANNOTATEMORE Extension", work in
progress, draft-daboo-imap-annotatemore-xx, (work in progress).
[GSM03.40] GSM 03.40 v7.4.0 Digital cellular telecommunications
system (Phase 2+); Technical realization of the Short Message
Service (SMS). ETSI 2000
[IMAP-DISC] Melnikov, A. "Synchronization operations for
disconnected IMAP4 clients", draft-melnikov-imap-disc-06.txt,
October 2004.
[IMAP-EVENTS] Melnikov, A. " Lemonade Inband Notifications",
draft-melnikov-lemonade-imap-events-00.txt, June 17, 2006
[IMAPSIEVE] Leiba, B., "Support for Sieve in Internet Message Access
Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-0x (work in
progress).
[LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile",
draft-ietf-lemonade-profile-XX.txt, (work in progress).
[LEMONADEPROFILEBIS] Maes, S.H., Melnikov A. and D. Cridland, "
LEMONADE profile bis", draft-ietf-lemonade-profile-bis-xx.txt, (work
in progress).
[MANAGESIEVE] Martin, T. and A. Melnikov, "A Protocol for Remotely
Managing Sieve Scripts", draft-martin-managesieve-xx.txt, (work in
progress).
Gellens [Page 13] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
[MSGEVENTS] Newman, C., "Internet Message Store Events", draft-
newman-lemonade-msgevent-xx.txt, (work in progress).
[NOTIFICATIONPROTOCOL] Maes, S.H., " Lemonade Notification protocol
", draft-ietf-lemonade-notification-protocol-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
[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).
[RECONNECT] A. Melnikov, C. Wilson, "IMAP4 Extensions for Quick
Reconnect", draft-ietf-lemonade-reconnect-06.txt, May 2006
[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)
[URLAUTH] Crispin, M. and Newman, C., "Internet Message Access
Protocol (IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth-
XX.txt, (work in progress).
[VFOLDER] Maes, S. and et Al., "Persistent Search Extensions and
Virtual Folder to the IMAP Protocol", draft-maes-lemonade-vfolder-
0x, (work in progress).
Gellens [Page 14] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
[WAPWDP] Wireless Datagram Protocol, Version 14-Jun-2001, Wireless
Application Protocol WAP-259-WDP- 20010614-aWAP (WDP)
9. Acknowledgments
The original, and significantly longer, version of this document was
authored by Stephane H. Maes and Ray Cromwell of Oracle Corporation.
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, including the original work on P-IMAP
[P-IMAP].
The authors want to thank the authors of the original work on Server
To Server Notification Protocol Requirements (draft-ietf-lemonade-
notify-s2s-00) whose material has been incorporated in the present
document, in particular, Gev Decktor.
10. Author's Address
Editor:
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
randy@qualcomm.com
Authors:
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
Ray Cromwell
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Gellens [Page 15] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
Appendix A: Changes from Previous Versions
THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION.
version -05:
* Significant deletion of sections, per
www1.ietf.org/mail-archive/web/lemonade/current/msg03936.html
version -04:
* Update dates, slight reformatting, add editor's note for
References
version -03:
* Updated examples to use new METADATA syntax
* Drop CLEARIDLE and reference A. Melnikov's [IMAP-EVENTS]
* XEMN notification format extended to with event and view
attributes
* 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)
* Added notification protocol details and reference
version -02:
* LPROVISION/LGETPREFS/LSETPREFS removed in favor of mailbox
annotations
* Updated inband notification section to include discussion of
[CLEARIDLE] and [MSGEVENTS]
* EMN payload clarified for both wakeup and extended formats.
* Some reference clean-up
* Add server to server notifications based on the expired draft
draft-ietf-lemonade-notify-s2s-00.
version -01:
* Move SMS / WAP examples to an informative appendix.
* Restrict the exchange of keys via LPROVISION to secure
exchanges.
* Differentiate ANNOTATE from LPROVISION on that basis.
versin -00:
* 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
Gellens [Page 16] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
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.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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.
Gellens [Page 17] Expires May 2008
Internet Draft Lemonade Notifications and Filters November 2007
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gellens [Page 18] Expires May 2008