Hi folks,
I took a stab at updating draft-martin-sieve-notify-01.txt, which should
be published soon as draft-ietf-sieve-notify-00.txt. The document is
attached.
The two major changes are:
1). updated the document to reference Sieve variables. Some notification
variables line "$text$" can't be mapped directly, but I will send a
separate message on this.
2). changed the document to use notification URIs, e.g. "sms:+123456789"
I remember there was a discussion few months ago about defining a
separate SMS notification mechanism. I just want to let people know that
the update I've made doesn't prevent any other documents in this area.
Just treat it as an input for discussion.
Alexey
Network Working Group Alexey Melnikov
Document: draft-ietf-sieve-notify-00.txt Editor
Expires March 2006 September 2005
Sieve -- An extension for providing instant notifications
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.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Users go to great lengths to be notified as quickly as possible that
they have received new mail. Most of these methods involve polling
to check for new messages periodically. A push method handled by the
final delivery agent gives users quicker notifications and saves
server resources. This document does not specify the notification
method but is expected that using existing instant messaging
infrastructure such as Zephyr, Jabber, or SMS messages will be popular.
This draft describes an extension to the Sieve mail filtering
language that allows users to give specific preferences for
notification of Sieve actions.
1. Introduction
This is an extension to the Sieve language defined by [SIEVE] for
providing instant notifications of sieve actions that have been
preformed. It defines the new action "notify".
This document does not dictate the notification method used.
Examples of possible notification methods are Zephyr and Jabber. The
method shall be site-defined.
Sieve interpreters for which notifications are impractical or is not
possible SHOULD ignore this extension.
Conventions for notations are as in [SIEVE] section 1.1, including
use of [KEYWORDS].
1.1. Conventions Used in This Document
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].
2. Capability Identifier
The capability string associated with the extension defined in this
document is "notify".
3. Actions
3.1. Notify action
Usage: notify [":method" string]
[":id" string]
[<":low" / ":normal" / ":high">]
[":message" string]
The Notify action specifies that a notification should be sent to
the user upon successful handling of this message.
The format of the notification is implementation-defined. However,
all content specified in the notify action, including Sieve actions
taken on the message, SHOULD be included. If errors occurred in
another action they SHOULD be reported in the notification. In
addition, if the notification method does not provide a timestamp,
one SHOULD be appended to the notification. Implementations SHOULD
NOT include extraneous information.
The :method tag identifies the notification method that will be
used, it is an URI. For examples, the notification method can
be an SMS URI [SMS-URI] containing a phone number, or an XMPP [XMPP]
URI containing Jabber identifier [XMPP-URI].
If the :method tag is not specified, the default
implementation defined notification method is used. The
possible values of this will be site-specific. If an URI schema is
specified that the implementation does not support, the notification
MUST be ignored. An implementation treats this as a warning
condition and execution of the sieve script MUST continue.
The :id tag can be used to give the notify action an unique
identifier. This identifier can be used later in the script to
cancel the specific notify. The string may have any value and SHOULD
NOT be included in the notification.
The priority parameter specifies the importance of the notification.
The priority parameter has the following values: ":high" (very
important), ":normal", and ":low" (not very important). If no
priority is given, a default priority of ":normal" SHOULD be
assumed. Some notification methods allow users to specify their
state of activity (for example "busy" or "away from keyboard"). If
the notification method provides this information it SHOULD be used
to selectively send notifications. If, for example, the user marks
herself as "busy", an implementation SHOULD NOT send a notification
for a new mailing list message with a priority of :low, however the
user should be notified of a high priority action. If the
notification method allows users to filter messages based upon
certain parameters in the message, users should be able to filter
based upon priority. If the notification method does not support
priority, then this parameter MUST be ignored.
The :message tag specifies the message data to be included in the
notification. The entirety of the string SHOULD be sent but
implementations MAY shorten the message for technical or aesthetic
reasons. If the message parameter is absent, a default message
containing the value of the From header field and the value of the
Subject header field will be used. Note that the notification
method (the ":method" tag) may affect how this information is
formatted.
In order to construct more complex messages
the notify extension can be used together with the Sieve variables
extension [VARIABLES], as shown at the end of this section.
<<Open issue: the previous version of this draft has defined the two
variables that can't be currently represented:
$text$ - the first text/* part
$text[n]$ - the first n bytes of the first text/* part
>>
If there are errors sending the notification, the Sieve interpreter
SHOULD ignore the notification and not retry indefinitely.
This action MUST NOT cancel the implicit keep.
Example:
require ["notify", "fileinto", "variables"];
if header :contains "from" "boss(_at_)example(_dot_)org" {
notify :high :message "This is probably very important";
# Don't send any further notifications
stop;
}
if header :contains "to" "sievemailinglist(_at_)example(_dot_)org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the value of the From header
if header :matches "From" "*" {
set "from" "${1}";
}
notify :low :message "[SIEVE] ${from}: ${subject}";
fileinto "INBOX.sieve";
}
Example:
require ["notify", "fileinto", "variables", "envelope"];
if header :matches "from" "*(_at_)*(_dot_)example(_dot_)org" {
# :matches is used to get the MAIL FROM address
if envelope :all :matches "from" "*" {
set "env_from" " [really: ${1}]";
}
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the address from the From header
if address :matches :all "from" "*" {
set "from_addr" "${1}";
}
notify :message "${from_addr}${env_from}: ${subject}";
}
3.2. Denotify Action
Usage: denotify [MATCH-TYPE string] [<":low" / ":normal" / ":high">]
The denotify action can be used to cancel a previous notification.
If the priority, ":low" / ":normal" / ":high", is specified, then
only cancel those notifications with the specified priority. If a
MATCH-TYPE with a string is specified, then only those notifications
whose :id tag matches the specified string using the match-type
operator are canceled. The ascii-casemap comparator MUST be used.
If no notifications exist that match the search criteria, then the
denotify has no effect. A denotify only cancels notifications that
have already been requested. It is not possible to preemptively
cancel a notification.
The sequence:
denotify;
notify;
will still generate a notification. The denotify does not cancel
the notify.
The following table shows which notifies would get cancelled:
# what is cancelled
denotify # all notifications
denotify :matches "*" # all notifications with :id tag
denotify :high # all high priority notifications
denotify :is "foobar" # all notifications with id "foobar"
denotify :matches "foo*" :normal # all normal priority notifications
# with id that starts with "foo"
Example:
require ["notify", "variables"];
notify :method
"xmpp:tim(_at_)example(_dot_)com?You%20got%20mail&subject=SIEVE"
:id "foobar";
if header :contains "from" "boss(_at_)example(_dot_)org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
notify :method "sms:+14085551212" :id "foobar"
:high :message "BOSS: ${subject}";
}
if header :contains "to" "sievemailinglist(_at_)example(_dot_)org" {
denotify :is "foobar";
}
if header :contains "subject" "FYI:" {
# don't need high priority notification for
# a 'for your information'
denotify :is "foobar" :high;
}
4. Interaction with Other Sieve Actions
Notifications MUST be sent in all cases, unless a reject action is
also executed. Users may wish to be notified of a message being
discarded, for example. <<The reject action is given an exception
because implementations may wish to restrict users from seeing the
contents of a rejected message. However, notifications MAY be
modified to not include any data from the original rejected message.>>
The notify action MUST NOT cancel the implicit keep.
The notify action is compatible with itself.
The denotify action MUST NOT affect any actions other than the
notify action.
Failures of other actions MAY be reported in the notification.
5. Security Considerations
Security considerations are discussed in [SIEVE]. Additionally
implementations must be careful to follow the security
considerations of the specific notification methods. It is believed
that this extension does not introduce any additional security
concerns.
The notify action is potentially very dangerous. The path the
notification takes through the network may not be secure. An error
in the options string may cause the message to be transmitted to
someone it was not intended for.
Just because a notification is received doesn't mean it was sent by
the sieve implementation. It might be possible to forge
notifications with some notification methods.
6. IANA Considerations
The following template specifies the IANA registration of the
variables Sieve extension specified in this document:
To: iana(_at_)iana(_dot_)org
Subject: Registration of new Sieve extension
Capability name: notify
Capability keyword: notify
Capability arguments: N/A
Standards Track/IESG-approved experimental RFC number:
this RFC
Person and email address to contact for further information:
Alexey Melnikov <Alexey(_dot_)Melnikov(_at_)isode(_dot_)com>
This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.
7. Acknowledgments
Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Barry
Leiba, and Cyrus Daboo for help with this document.
8. References
8.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
November 1997. <<needs updating>>
[SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering
Language", work in progress, draft-ietf-sieve-3028bis-XX.txt.
8.2. Informative References
[VARIABLES] Homme, K., "Sieve Extension: Variables", work in
progress, draft-ietf-sieve-variables-XX.txt.
[XMPP]
[XMPP-URI] Saint-Andre, P., "A Uniform Resource Identifier (URI)
Scheme for the Extensible Messaging and Presence Protocol (XMPP)",
work in progress, draft-saintandre-xmpp-uri-XX.txt.
[SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short
Message Service", work in progress, draft-wilde-sms-uri-XX.txt.
9. Author's and Editor's Addresses
Tim Martin
Mirapoint Inc.
909 Hermosa Court
Sunnyvale, CA 94085
Phone: (408) 720-3835
EMail: tmartin(_at_)mirapoint(_dot_)com
Wolfgang Segmuller
IBM T.J. Watson Research Center
30 Saw Mill River Rd
Hawthorne, NY 10532
Phone: (914) 784-7408
Email: whs(_at_)watson(_dot_)ibm(_dot_)com
Alexey Melnikov (Editor)
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex
TW12 2BX, UK
Email: Alexey(_dot_)Melnikov(_at_)isode(_dot_)com
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(_at_)ietf(_dot_)org(_dot_)
Disclaimer of Validity
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
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.