< draft-martin-sieve-notify-00.txt		draft-martin-sieve-notify-01.txt >
	Network Working Group Tim Martin		Network Working Group Tim Martin
	Document: draft-martin-sieve-notify-00.txt Mirapoint Inc.		Document: draft-martin-sieve-notify-01.txt Wolfgang Segmuller
	Expires June 9, 2001 4 December 2000		Expires December 6, 2001 1 June 2001
	Sieve -- An extension for providing instant notifications		Sieve -- An extension for providing instant notifications
	<draft-martin-sieve-notify-00.txt>		<draft-ietf-sieve-notify-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are		all provisions of Section 10 of RFC2026. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet- Drafts as		at any time. It is inappropriate to use Internet- Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	Abstract		Abstract
	Users go to great lengths to be notified as quickly as possible that		Users go to great lengths to be notified as quickly as possible that
	they have received new mail. Most of these methods involve polling		they have received new mail. Most of these methods involve polling
	to check for new messages periodically. A push method handled by the		to check for new messages periodically. A push method handled by the
	final delivery agent would give users quicker notifications and save		final delivery agent gives users quicker notifications and saves
	server resources. This draft describes an extension to the Sieve		server resources. This document does not specify the notification
	mail filtering language that allows users to give specific		method but is expected that using existing instant messaging
	preferences for notification of Sieve actions.		infrastructure such as Zephyr, ICQ, 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.
	TTaabbllee ooff CCoonntteennttss		TTaabbllee ooff CCoonntteennttss
	Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1		Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1
	Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1		Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
			1.1. Conventions Used in This Document . . . . . . . . . . . . . . 3
	2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3		2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3
	3. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Notify action . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Notify action . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Denotify action . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Denotify Action . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Default action . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Interaction with Other Sieve Actions . . . . . . . . . . . . 5
	5. Interaction with Other Sieve Actions . . . . . . . . . . . . 5		4. Interaction with Other Sieve Actions . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7		9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	This is an extension to the Sieve language defined by [SIEVE] for		This is an extension to the Sieve language defined by [SIEVE] for
	providing instant notifications of sieve actions that have been		providing instant notifications of sieve actions that have been
	preformed. It defines the new action "notify".		preformed. It defines the new action "notify".
	This document does not dictate the notification method used. The		This document does not dictate the notification method used.
			Examples of possible notification methods are Zephyr and ICQ. The
	method shall be site-defined.		method shall be site-defined.
	Sieve interpreters for which notifications are impractical or is not		Sieve interpreters for which notifications are impractical or is not
	possible SHOULD ignore this extension.		possible SHOULD ignore this extension.
	Conventions for notations are as in [SIEVE] section 1.1, including		Conventions for notations are as in [SIEVE] section 1.1, including
	use of [KEYWORDS].		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		2. Capability Identifier
	The capability string associated with the extension defined in this		The capability string associated with the extension defined in this
	document is "notify".		document is "notify".
	3. Actions		3. Actions
	3.1. Notify action		3.1. Notify action
	Syntax: notify <priority> <message> [<list of headers to include>]		Syntax: notify [":method" string]
			[":id" string]
			[":options" 1*(string-list / number)]
			[<":low" / ":normal" / ":high">]
			["message:" string]
	The Notify action specifies that a notification should be sent to		The Notify action specifies that a notification should be sent to
	the user upon successful handling of this message.		the user upon successful handling of this message.
	The format of the notification is site-defined. However, all		The format of the notification is implementation-defined. However,
	content, including Sieve actions taken on the message, specified in		all content specified in the notify action, including Sieve actions
	the notify action MUST be included. If errors occurred in another		taken on the message, SHOULD be included. If errors occurred in
	action they SHOULD be reported in the notification. In addition, if		another action they SHOULD be reported in the notification. In
	the notification method does not provide a timestamp, one SHOULD be		addition, if the notification method does not provide a timestamp,
	appended to the notification. Implementations SHOULD NOT include		one SHOULD be appended to the notification. Implementations SHOULD
	extraneous information.		NOT include extraneous information.
	The "priority" parameter specifies the importance of the		The :method tag identifies the notification method that will be
	notification. The priority parameter shall range from :high (very		used. If the :method tag is not specified, the default
	important) to :medium (moderately important) to :low (not very		implementation defined notification method MUST be used. The
	important). If no priority is giving it shall default to "medium".		possible values of this will be site-specific. If a method 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.
	Some instant notification methods allow users to specify their state		The :id tag can be used to give the notify action an unique
	of activity (for example "busy" or "away from keyboard"). If the		identifier. This identifier can be used later in the script to
	notification method provides this information it SHOULD be used to		cancel the specific notify. The string may have any value and SHOULD
	selectively send notifications. If for example the user marks		NOT be included in the notification.
	herself as "busy" an implentation SHOULD NOT send a notification for
	a new mailing list message with a priority of :low, however a 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.
	The "message" parameter specifies the message to be included in the		The :options tag is used to send parameters to the notification
			method. This might be the phone number for an SMS message or a
			user's ICQ identifier.
			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		notification. The entirety of the string SHOULD be sent but
	implementations MAY shorten the message for technical or aesthetic		implementations MAY shorten the message for technical or aesthetic
	reasons.		reasons. Message may include the message variables defined below. If
			the message parameter is absent, a default message of "$from$:
			$subject$" will be used.
	The list of headers specifies which headers the user wishes to be		$from$ - the display name or address of the RFC 822 from
	notified of. The header and its contents MUST both be displayed. If		$env-from$ - the address of the RFC 821 from
	this parameter is omitted, the "From", "To", and "Subject" headers
	shall be displayed by default.		$subject$ - the subject of the message
			$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		If there are errors sending the notification, the Sieve interpreter
	SHOULD ignore the notification and not retry indefinitely.		SHOULD ignore the notification and not retry indefinitely.
	At maximum, one notification is sent per message. If a message		This action MUST NOT cancel the implicit keep.
	yields multiple notify actions in the processing of a script, the
	notify action with the highest priority MUST be used. If there are
	multiple notify actions with the same priority the last one with
	that priority shall be used.
	Example:		Example:
	if header :contains "from" "brian_bitono@foo.org" {		require ["notify","fileinto"];
	notify :high "This is probably very important";
			if header :contains "from" "boss@example.org" {
			notify :high "This is probably very important";
	}		}
	if header :contains "to" "mailinglist@cmu.edu" {		if header :contains "to" "sievemailinglist@example.org" {
	notify :low "" "" ["From", "Subject"];		notify :low "[SIEVE] $from$: $subject$";
	fileinto "INBOX.mailing-list";		fileinto "INBOX.sieve";
	}		}
	3.2. Denotify action		3.2. Denotify Action
	Syntax: denotify		Syntax: denotify [MATCH-TYPE string] [<":low" / ":normal" /
			":high">]
	The denotify action specifies that the current notification, if any,		The denotify action can be used to cancel a previous notification.
	shall not be sent.		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.
	Example:		If no notifications exist that match the search criteria, then the
	notify "" "New mail";		denotify has no effect. A denotify only cancels notifications that
			have already been requested. It is not possible to preemptively
			cancel a notification.
	if header :contains "from" "mymom@baz.org" {		The sequence:
	denotify;
	fileinto "INBOX.junk";
	}
	3.3. Default action		denotify;
			notify;
	If neither the notify or denotify action is encountered by default a		will still generate a notification. The denotify does not cancel
	notifications SHOULD be sent. This notification shall be equivalent		the notify.
	to a notify action with a priority of medium and the default headers
	specified. The message shall be site defined.
	4. Interaction with Other Sieve Actions		The following table shows which notifies would get cancelled:
	Notifications MUST be sent no matter what the message actions might		# what is cancelled
	be. Users may wish to know when messages are being discarded or		denotify # all notifications
	rejected.		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"
	5. Interaction with Other Sieve Actions		Example:
			require "notify";
	The following syntax specification uses the augmented Backus-Naur		notify :method "sms" :options "408-555-1212" :id "foobar";
	Form (BNF) notation as specified in [ABNF]. This uses the ABNF core		if header :contains "from" "boss@example.org" {
	rules as specified in Appendix A of the ABNF specification [ABNF].		notify :method "sms" :options "408-555-1212" :id "foobar" :high
			:message "BOSS: $subject$";
			}
	capability =/ notify		if header :contains "to" "sievemailinglist@example.org" {
			denotify :is "foobar";
			}
	action =/ notify / denotify		if header :contains "subject" "FYI:" {
			# don't need high priority notification for
			# a 'for your information'
			denotify :is "foobar" :high;
			}
	priority = :low / :medium / :high /		4. Interaction with Other Sieve Actions
	notify = "notify" WSP priority WSP string WSP string-list		Notifications MUST be sent in all cases, unless a reject action is
	;; <priority> <message> <headers-list>		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.
	denotify = "denotify"		The notify action MUST NOT cancel the implicit keep.
	6. Security Considerations		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		Security considerations are discussed in [SIEVE]. Additionally
	implementations must be careful to follow the security		implementations must be careful to follow the security
	considerations of the specific notification methods. It is believed		considerations of the specific notification methods. It is believed
	that this extension does not introduce any additional security		that this extension does not introduce any additional security
	concerns.		concerns.
	7. Acknowledgments		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.
	Thanks to Larry Greenfield and Sarah Robeson for help with this		Just because a notification is received doesn't mean it was sent by
	document.		the sieve implementation. It might be possible to forge
			notifications with some notification methods.
	8. Copyright		6. Acknowledgments
			Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, and Barry
			Leiba for help with this document.
			7. Copyright
	Copyright (C) The Internet Society 1999. All Rights Reserved.		Copyright (C) The Internet Society 1999. All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this		are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	skipping to change at page 6, line 46 ¶		skipping to change at page 8, line 18 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	9. References		8. References
	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].
	[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:		[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
	ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,		ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
	November 1997.		November 1997.
	[SIEVE] Showalter, T, "Sieve -- a Mail Filtering Language", draft-		[SIEVE]; Showalter, T.; "Sieve: A Mail Filtering Language"; RFC
	showalter-sieve-09.txt, Mirapoint, September 1999.		3028; Mirapoint, Inc.; January 2001
	10. Author's Address		9. Author's Addresses
	Tim Martin		Tim Martin
	Mirapoint Inc.		Mirapoint Inc.
	909 Hermosa Court		909 Hermosa Court
	Sunnyvale, CA 94085		Sunnyvale, CA 94085
	Phone: (408) 720-3835		Phone: (408) 720-3835
	EMail: tmartin@mirapoint.com		EMail: tmartin@mirapoint.com
			Wolfgang Segmuller
			IBM T.J. Watson Research Center
			30 Saw Mill River Rd
			Hawthorne, NY 10532
			Phone: (914) 784-7408
			Email: whs@watson.ibm.com
End of changes. 49 change blocks.
	97 lines changed or deleted		162 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/