< draft-ietf-sieve-notify-presence-03.txt		draft-ietf-sieve-notify-presence-04.txt >
	Sieve working group R. George		Sieve working group R. George
	Internet-Draft B. Leiba		Internet-Draft B. Leiba
	Intended status: Standards Track Huawei Technologies		Intended status: Standards Track Huawei Technologies
	Expires: June 1, 2011 November 28, 2010		Expires: June 18, 2011 December 15, 2010
	Sieve Notification Using Presence Information		Sieve Notification Using Presence Information
	draft-ietf-sieve-notify-presence-03		draft-ietf-sieve-notify-presence-04
	Abstract		Abstract
	This is a further extension to the Sieve mail filtering language		This is a further extension to the Sieve mail filtering language
	Notification extension, defining presence information that may be		Notification extension, defining presence information that may be
	checked through the notify_method_capability feature.		checked through the notify_method_capability feature.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 1, 2011.		This Internet-Draft will expire on June 18, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology Used in This Document . . . . . . . . . . . . . . 3		1.1. Terminology Used in This Document . . . . . . . . . . . . . . 3
	2. Testing presence information . . . . . . . . . . . . . . . . 3		2. Testing presence information . . . . . . . . . . . . . . . . 3
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to		Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to
	a user's current situation. Presence information provides some		a user's current situation. Presence information provides some
	information about the user that would be useful to have access to in		information about the user that would be useful to have access to in
	these cases. The Notification extension [RFC5435] defines a		these cases. The Notification extension [RFC5435] defines a
	mechanism to test for presence (the notify_method_capability		mechanism to test for presence (the notify_method_capability
	feature), and defines one test for presence (the "online"		feature), and defines one test for presence (the "online"
	notification-capability, described in Section 5 of RFC 5435). This		notification-capability, described in Section 5 of RFC 5435). This
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	This extension uses the notify_method_capability test, as defined in		This extension uses the notify_method_capability test, as defined in
	the Sieve [RFC5228] Notify extension [RFC5435], to test presence		the Sieve [RFC5228] Notify extension [RFC5435], to test presence
	information. When a Sieve event occurs (mail arrives) for a user, a		information. When a Sieve event occurs (mail arrives) for a user, a
	Sieve script running on behalf of that user can present the user's		Sieve script running on behalf of that user can present the user's
	presence URI (in the "notification-uri" parameter) and test a		presence URI (in the "notification-uri" parameter) and test a
	specific item of notification presence as defined below (in the		specific item of notification presence as defined below (in the
	"notification-capability" parameter) against one or more values (in		"notification-capability" parameter) against one or more values (in
	the "key-list" parameter).		the "key-list" parameter).
	This document defines a set of items of notification presence, which		This document defines an initial set of items of notification
	may be specified in the notification-capability parameter. The		presence, which may be specified in the notification-capability
	script tests the values of notification presence items in the key-		parameter. It is expected that future extensions will add additional
	list parameter. The values that each item may have are specified in		presence items derived from diverse sources, including calendar
	the list below. Note that in addition to the presence values, any		information, geographic location, and so on.
	item may have the value "unknown" if it is not possible to determine
	the correct presence value of the item.		Note that, while the items below are documented as similar to items
			in XMPP, it is not the intent that this extension be tied to XMPP,
			nor to any particular source of presence, and flexible
			implementations will be ready for future extensions. Useful
			informational references for presence data and formats include
			Presence Information Data Format (PIDF) [RFC3863], RPID: Rich
			Presence Extensions to PIDF [RFC4480], and GEOPRIV Presence
			Information Data Format Location Object (PIDF-LO) [RFC5491].
			The script tests the values of notification presence items in the
			key- list parameter. The values that each item may have are
			specified in the list below. Note that in addition to the presence
			values, any item may have the value "unknown" if it is not possible
			to determine the correct presence value of the item.
	If a particular presence item is tested multiple times within the		If a particular presence item is tested multiple times within the
	same script execution context, implementations MUST present the same		same script execution context, implementations MUST present the same
	value each time (for example, by caching the value on first use).		value each time (for example, by caching the value on first use).
	This provides consistency within a single execution.		This provides consistency within a single execution.
	Supported presence items are as follows:		Supported presence items are as follows:
	busy - An indication of whether the user is considered "busy" now		busy - An indication of whether the user is considered "busy" now
	(the value "yes") or not (the value "no"), or "unknown" if it		(the value "yes") or not (the value "no"), or "unknown" if it
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 31 ¶
	show - The availability status of the user, formally specified. Note		show - The availability status of the user, formally specified. Note
	that this is similar to the presence element with the same name		that this is similar to the presence element with the same name
	that's defined in Section 2.2.2.1 of RFC 3921.[RFC3921] The		that's defined in Section 2.2.2.1 of RFC 3921.[RFC3921] The
	value of this item is one of the following:		value of this item is one of the following:
	away - The user is temporarily away.		away - The user is temporarily away.
	chat - The user is online and actively interested in chatting.		chat - The user is online and actively interested in chatting.
	dnd - Do Not Disturb; the user should not be disturbed now.		dnd - Do Not Disturb; the user does not wish to be disturbed
			now.
	offline - The user is offline.		offline - The user is offline.
	xa - The user is away for an extended period (xa = "eXtended		xa - The user is away for an extended period (xa = "eXtended
	Away").		Away").
	unknown - The correct presence value could not be determined.		unknown - The correct presence value could not be determined.
	status - A human-readable description of the user's availability		status - A human-readable description of the user's availability
	status. There is no formal definition for the values this item		status, in natural language. There is no formal definition for
	may take. It is free-form, and may be in any language. Direct		the values this item may take. It is free-form, and may be in
	comparisons against the value of this field are unlikely to be		any language. Direct comparisons against the value of this
	useful; rather, it is provided to enable extraction of the value		field are unlikely to be useful; rather, it is provided to
	into a variable [RFC5229] for use elsewhere (see example 3 in		enable extraction of the value into a variable [RFC5229] for use
	Section 3). Note that this is similar to the presence element		elsewhere (see example 3 in Section 3). Note that this is
	with the same name that's defined in Section 2.2.2.2 of RFC		similar to the presence element with the same name that's
	3921.[RFC3921]		defined in Section 2.2.2.2 of RFC 3921 [RFC3921], and to the
			<note> element defined in section 4.1.6 of PIDF [RFC3863].
			Because this is a free-form value that might be created directly
			by a user, no value, including "unknown", can have any special
			meaning. If the Sieve processor is unable to determine the
			value of this item, it might be best to leave it as an empty
			string. In any case, it is not meant for machine-readable
			processing, beyond possible XML interpretation.
	There is no capability string associated with this extension, but		There is no capability string associated with this extension, but
	this requires support for "enotify".[RFC5435] If the implementation		this requires support for "enotify".[RFC5435] If the implementation
	does not support the item being tested (that is, the specified		does not support the item being tested (that is, the specified
	notification-capability item is not known to the Sieve interpreter),		notification-capability item is not known to the Sieve interpreter),
	RFC 5435 already specifies that the test fail without an error.		RFC 5435 already specifies that the test fail without an error.
	Although this feature was conceived to assist in notifications, and		Although this feature was conceived to assist in notifications, and
	the test requires support of the Sieve Notify feature, it is only a		the test requires support of the Sieve Notify feature, it is only a
	condition test, and any Sieve action can appear inside it. There are		condition test, and any Sieve action can appear inside it. There are
	skipping to change at page 8, line 33 ¶		skipping to change at page 9, line 5 ¶
	George, R., Leiba, B., and A. Melnikov, "Sieve Email		George, R., Leiba, B., and A. Melnikov, "Sieve Email
	Filtering: Use of Presence Information with Auto Responder		Filtering: Use of Presence Information with Auto Responder
	functionality", draft-ietf-sieve-autoreply-02 (work in		functionality", draft-ietf-sieve-autoreply-02 (work in
	progress), October 2010.		progress), October 2010.
	[I-D.ietf-sieve-external-lists]		[I-D.ietf-sieve-external-lists]
	Melnikov, A. and B. Leiba, "Sieve Extension: Externally		Melnikov, A. and B. Leiba, "Sieve Extension: Externally
	Stored Lists", draft-ietf-sieve-external-lists-02 (work in		Stored Lists", draft-ietf-sieve-external-lists-02 (work in
	progress), May 2010.		progress), May 2010.
			[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
			W., and J. Peterson, "Presence Information Data Format
			(PIDF)", RFC 3863, August 2004.
			[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
			Rosenberg, "RPID: Rich Presence Extensions to the Presence
			Information Data Format (PIDF)", RFC 4480, July 2006.
	[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",		[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
	RFC 5229, January 2008.		RFC 5229, January 2008.
	[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:		[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:
	Vacation Extension", RFC 5230, January 2008.		Vacation Extension", RFC 5230, January 2008.
			[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
			Presence Information Data Format Location Object (PIDF-LO)
			Usage Clarification, Considerations, and Recommendations",
			RFC 5491, March 2009.
	Authors' Addresses		Authors' Addresses
	Robins George		Robins George
	Huawei Technologies		Huawei Technologies
	Bangalore, Karnataka 560071		Bangalore, Karnataka 560071
	India		India
	Phone: +91-080-41117676		Phone: +91-080-41117676
	Email: robinsgv@gmail.com		Email: robinsgv@gmail.com
	Barry Leiba		Barry Leiba
	Huawei Technologies		Huawei Technologies
	Phone: +1 646 827 0648		Phone: +1 646 827 0648
	Email: barryleiba@computer.org		Email: barryleiba@computer.org
	URI: http://internetmessagingtechnology.org/		URI: http://internetmessagingtechnology.org/
End of changes. 12 change blocks.
	22 lines changed or deleted		58 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/