< draft-melnikov-sieve-notify-sip-message-00.txt		draft-melnikov-sieve-notify-sip-message-01.txt >
	Network Working Group A. Melnikov		Network Working Group A. Melnikov
	Internet-Draft Isode Limited		Internet-Draft Isode Limited
	Intended status: Standards Track H. Schulzrinne		Intended status: Standards Track H. Schulzrinne
	Expires: March 2, 2008 Columbia U.		Expires: August 20, 2008 Columbia U.
	Q. Sun		Q. Sun
	Huawei Technologies		Huawei Technologies
	August 30, 2007		February 17, 2008
	Sieve Notification Mechanism: SIP MESSAGE		Sieve Notification Mechanism: SIP MESSAGE
	draft-melnikov-sieve-notify-sip-message-00		draft-melnikov-sieve-notify-sip-message-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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."
	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/ietf/1id-abstracts.txt.
	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.
	This Internet-Draft will expire on March 2, 2008.		This Internet-Draft will expire on August 20, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document describes a profile of the Sieve extension for		This document describes a profile of the Sieve extension for
	notifications, to allow notifications to be sent over the SIP		notifications, to allow notifications to be sent over the SIP
	MESSAGE.		MESSAGE.
	Conventions Used in this Document		Conventions Used in this Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Notify parameter "method" . . . . . . . . . . . . . . . . . . 3		2.1. Notify parameter "method" . . . . . . . . . . . . . . . . . 3
	2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3		2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3
	2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . . 4		2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 3
	2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4		2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4
	2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . . 4		2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 4
	2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . . 4		2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . 4
			2.7. Test notify_method_capability . . . . . . . . . . . . . . . 4
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Internationalization Considerations . . . . . . . . . . . . . 5		4. Requirements Conformance . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
	7. Normative References . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 6		8. Normative References . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
			Intellectual Property and Copyright Statements . . . . . . . 10
	1. Introduction		1. Introduction
	1.1. Overview		1.1. Overview
	The NOTIFY [NOTIFY] extension to the SIEVE [SIEVE] mail filtering		The NOTIFY [NOTIFY] extension to the SIEVE [SIEVE] mail filtering
	language is a framework for providing notifications by employing URIs		language is a framework for providing notifications by employing URIs
	to specify the notification mechanism. This document defines how SIP		to specify the notification mechanism. This document defines how SIP
	URIs (see RFC 3261 [RFC3261]) are used to generate notifications via		URIs (see RFC 3261 [SIP]) are used to generate notifications via the
	the SIP MESSAGE (see RFC 3428 [RFC3428]).		SIP MESSAGE (see RFC 3428 [RFC3428]).
	1.2. Terminology		1.2. Terminology
	This document inherits terminology from NOTIFY [NOTIFY], SIEVE		This document inherits terminology from NOTIFY [NOTIFY], SIEVE
	[SIEVE], and RFC 3261 [RFC3261].		[SIEVE], and RFC 3261 [SIP].
	2. Definition		2. Definition
	The sip message mechanism results in the sending of a SIP MESSAGE		The sip message mechanism results in the sending of a SIP MESSAGE
	request to notify a recipient about an email message.		request to notify a recipient about an email message.
	2.1. Notify parameter "method"		2.1. Notify parameter "method"
	The "method" parameter MUST be a URI that conforms to the SIP (or		The "method" parameter MUST be a URI that conforms to the SIP (or
	SIPS) URI scheme (as specified in RFC 3261 [RFC3261]) and that		SIPS) URI scheme (as specified in RFC 3261 [SIP]) and that identifies
	identifies a SIP (or SIPS) URI. The URI MAY include the resource		a SIP (or SIPS) recipient of the notification. The URI MAY include
	identifier portion of a SIP address and URI parameters. The URI		the resource identifier portion of a SIP address and URI parameters.
	parameter "method" MUST be ignored, because only MESSAGE method is		The URI parameter "method" MUST be ignored, because only the MESSAGE
	allowed by this specification. The processing application MUST		method is allowed by this specification. The processing application
	extract a SIP address from the URI in accordance with the processing		MUST extract a SIP address from the URI in accordance with the
	rules specified in RFC 3261 [RFC3261]. The resulting SIP address		processing rules specified in RFC 3261 [SIP]. The resulting SIP
	MUST be encapsulated in SIP URI syntax as Request-URI and the value		address MUST be encapsulated in SIP URI syntax as Request-URI and the
	of the "To" header field of the SIP MESSAGE request.		value of the "To" header field of the SIP MESSAGE request.
	2.2. Notify tag ":from"		2.2. Notify tag ":from"
	The ":from" tag has no special meaning for this notification		The value of the ":from" tag MUST use the SIP "Reply-To" syntax; if
	mechanism, and this specification puts no restriction on its use. As		the :from value is specified and has valid syntax, the notification
	noted, the value of the SIP "From" header field specified in the SIP		MUST include the "Reply-To" SIP header field containing the value of
	notification message MUST be the SIP address of the notification		the :from notify tag. If the value has invalid syntax, this is
	service itself. The value of the ":from" tag MUST use the SIP		considered a Sieve script processing error. [[anchor6: Should the
	"Reply-To" syntax; if the :from value is specified and has valid		value be ignored instead?]]
	syntax, it MUST be encapsulated as the value of a SIP header field
	named "Reply-To". If the value has invalid syntax, this is
	considered a Sieve script processing error.
	2.3. Notify tag ":options"		2.3. Notify tag ":options"
	This tag is not used by this method.		Handling of the ":options" tag is implementation specific. This
			document doesn't require presence of any option and doesn't define
			how options are processed.
	2.4. Notify tag ":importance"		2.4. Notify tag ":importance"
	The value of the ":importance" tag MAY be transformed into SIP		The value of the ":importance" tag MAY be transformed into SIP
	"Priority" header field (in addition to or instead of including in		"Priority" header field (in addition to or instead of including in
	the default message); if specified, the value of the "Priority"		the default message); if specified, the value of the "Priority"
	header field MUST be "urgent" if the value of the ":importance" tag		header field MUST be "urgent" if the value of the ":importance" tag
	is "1", "normal" if the value of the ":importance" tag is "2", or		is "1", "normal" if the value of the ":importance" tag is "2", or
	"non-urgent" if the value of the ":importance" tag is "3".		"non-urgent" if the value of the ":importance" tag is "3".
	2.5. Notify tag ":message"		2.5. Notify tag ":message"
	If included, the ":message" tag MUST be transformed into the message-		If included, the ":message" tag MUST be transformed into the message-
	body of a SIP MESSAGE, which SHOULD have Content-Type value of "text/		body of a SIP MESSAGE, which MUST have Content-Type value of "text/
	plain". If not included, the rule specified in NOTIFY [NOTIFY]		plain" with CHARSET="UTF-8". [[anchor10: Should application/
	SHOULD be followed, as shown in the examples below.		sieve-notification+xml Content type from draft-mahy-sieve-notify-sip
			be used instead?]] If not included, the default message body SHOULD
			contain values of the "From" and "Subject" header fields of the
			triggering email message (and MAY include the value of the
			":importance" tag, if one is specified), as shown in one of the
			examples below.
	2.6. Other Definitions		2.6. Other Definitions
			The value of the SIP "From" header field specified in the SIP
			notification message MUST be the SIP address of the notification
			service itself.
	An implementation MUST ignore any URI parameter it does not		An implementation MUST ignore any URI parameter it does not
	understand (i.e., the URI MUST be processed as if the parameter were		understand (i.e., the URI MUST be processed as if the parameter were
	not present). It is RECOMMENDED not to use the hname "body"		not present). It is RECOMMENDED not to use the hname "body"
	parameter value as the message-body of the SIP MESSAGE request. If		parameter value as the message-body of the SIP MESSAGE request. If
	hname "body" parameter and ":message" tag are presented at the same		hname "body" parameter and ":message" tag are present at the same
	time, the "body" parameter MUST be ignored.		time, the "body" parameter MUST be ignored.[[anchor11: Any other SIP
			URI parameters that should be used?]]
	The policy of retry delivery of a notification is a matter of		The policy of retry delivery of a notification is a matter of
	implementation and is not specified herein. But it SHOULD follow the		implementation and is not specified herein. But it SHOULD follow the
	suggestion for retry in RFC 3261 [RFC3261].		suggestion for retry in RFC 3261 [SIP].
			2.7. Test notify_method_capability
			The notify_method_capability test for "online" may return "yes" or
			"no" only if the Sieve processor can determine with certainty whether
			or not the recipient of the notification message is can receive the
			notification immediately. Otherwise, the test returns "maybe" for
			this notification method. [[anchor12: Add some specific details
			regarding determining online status of the recipient. Also need to
			add some text about presence leak?]]
	3. Examples		3. Examples
	In the following examples, the sender of the email has an address of		In the following examples, the sender of the email has an address of
	<mailto:juliet@example.org>, the entity to be notified has a SIP		juliet@example.org, the entity to be notified has a SIP address of
	address of <sip:romeo@example.com>, and the notification service has		<sip:romeo@example.com>, and the notification service has a SIP
	a SIP address <sip:notifier@example.com>.		address <sip:notifier@example.com>.
	The following is a basic Sieve notify action with only a method:		The following is a basic Sieve notify action with only a method:
	notify "sip:romeo@example.com"		notify "sip:romeo@example.com"
	The resulting SIP MESSAGE request might be as follows:		The resulting SIP MESSAGE request might be as follows:
	MESSAGE sip:romeo@example.com SIP/2.0		MESSAGE sip:romeo@example.com SIP/2.0
	Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse		Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse
	Max-Forwards: 70		Max-Forwards: 70
	From: sip:notifier@example.com;tag=32328		From: sip:notifier@example.com;tag=32328
	To: sip:romeo@example.com		To: sip:romeo@example.com
	Call-ID: asd88asd77a@1.2.3.4		Call-ID: asd88asd77a@1.2.3.4
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	Content-Type: text/plain		Content-Type: text/plain
	Content-Length: 43		Content-Length: 53
	juliet@example.com; Contact me immediately!		<juliet@example.com> wrote: Contact me immediately!
			In the example above the email message was received from
			juliet@example.com and had "Subject: Contact me immediately!"
	The following is a more advanced Sieve notify action with a method,		The following is a more advanced Sieve notify action with a method,
	importance, subject, and message:		importance, subject, and message:
	notify :importance "1"		notify :importance "1"
	:message "Contact Juliet immediately!"		:message "You got new mail!"
	"sip:romeo@example.com?subject=SIEVE"		"sip:romeo@example.com?subject=SIEVE"
	MESSAGE sip:romeo@example.com SIP/2.0		MESSAGE sip:romeo@example.com SIP/2.0
	Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse		Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse
	Max-Forwards: 70		Max-Forwards: 70
	From: sip:notifier@example.com;tag=32328		From: sip:notifier@example.com;tag=32328
	To: sip:romeo@example.com		To: sip:romeo@example.com
	Subject: SIEVE		Subject: SIEVE
	Priority: urgent		Priority: urgent
	Call-ID: asd88asd77a@1.2.3.4		Call-ID: asd88asd77a@1.2.3.4
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	Content-Type: text/plain		Content-Type: text/plain
	Content-Length: 27		Content-Length: 19
	Contact Juliet immediately!		You got new mail!
	4. Internationalization Considerations		4. Requirements Conformance
	TBD		Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve
			notification methods. The conformance of the SIP MESSAGE
			notification mechanism is provided here.[[anchor15: This section
			needs more work.]]
			1. An implementation of the SIP MESSAGE notification method SHOULD
			NOT modify the final notification text (e.g., to limit the
			length); however, a given deployment MAY do so. Modification of
			characters themselves should not be necessary, since SIP MESSAGE
			body is encoded in UTF-8 [RFC3629].
			2. An implementation MAY ignore parameters specified in the
			":importance", and ":options" tags.
			3. If not included, the default message body SHOULD contain values
			of the "From" and "Subject" header fields of the triggering
			email message (and MAY include the value of the ":importance"
			tag, if one is specified), as shown in one of the examples
			below.
			4. A notification sent via the SIP message notification method MAY
			include a timestamp in the textual message. [[anchor16: Should
			the SIP Date header field be used for timestamp instead?]]
			5. The value of the SIP "From" header field MUST be the SIP address
			of the notification service associated with the SIEVE engine.
			6. The value of the Sieve ":from" tag MUST be transformed into the
			value of an SIP "Reply-To" header field.
			7. The value of the SIP "To" header field MUST be the SIP address
			specified in the SIP URI contained in the "method" parameter.
			8. An implementation MUST ignore any URI parameters it does not
			understand (i.e., the URI MUST be processed as if the action or
			parameter were not present). See Section 2.6 for more details.
			9. An implementation MUST NOT include any other extraneous
			information not specified in parameters to the notify action.
			10. The notify_method_capability test for the "online" notification-
			capability behaves as described in Section 2.7.
	5. Security Considerations		5. Security Considerations
			[[anchor17: TBD]]
			Depending on the information included, sending a notification can be
			comparable to forwarding mail to the notification recipient. Care
			must be taken when forwarding mail automatically, to ensure that
			confidential information is not sent into an insecure environment or
			over an insecure channel.
	UAs that support the MESSAGE request MUST implement end-to-end		UAs that support the MESSAGE request MUST implement end-to-end
	authentication, body integrity, and body confidentiality mechanisms.		authentication, body integrity, and body confidentiality mechanisms.
	6. Acknowledgements		Other security considerations given in [NOTIFY], [SIEVE] and [SIP]
			are also relevant to this document.
	TBD		6. IANA Considerations
	7. Normative References		The following template provides the IANA registration of the Sieve
			notification mechanism specified in this document:
	[NOTIFY] Melnikov, A., "Sieve Extension: Notifications",		To: iana@iana.org
	draft-ietf-sieve-notify-08 (work in progress),		Subject: Registration of new Sieve notification mechanism
	February 2007.		Mechanism name: sip-message
			Mechanism URI: RFC 3261 [SIP]
			Mechanism-specific options: none
			Standards Track/IESG-approved experimental RFC number: [RFC XXXX]
			Person and email address to contact for further information:
			See authors of [RFC XXXX]
			This information should be added to the list of Sieve notification
			mechanisms maintained at
			<http://www.iana.org/assignments/sieve-notification>.
			7. Acknowledgements
			This document borrows some text from draft-ietf-sieve-notify-xmpp.
			8. Normative References
			[NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
			Martin, "Sieve Extension: Notifications",
			draft-ietf-sieve-notify-12 (work in progress),
			December 2007.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.
	[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,		[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
	and D. Gurle, "Session Initiation Protocol (SIP) Extension		and D. Gurle, "Session Initiation Protocol (SIP) Extension
	for Instant Messaging", RFC 3428, December 2002.		for Instant Messaging", RFC 3428, December 2002.
	[SIEVE] Guenther, P., "Sieve Extension: Notifications", Internet-		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	Draft Sieve: An Email Filtering Language, February 2007.		10646", STD 63, RFC 3629, November 2003.
			[SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
			Filtering Language", RFC 5228, January 2008.
			[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
			A., Peterson, J., Sparks, R., Handley, M., and E.
			Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			June 2002.
	Authors' Addresses		Authors' Addresses
	Alexey Melnikov		Alexey Melnikov
	Isode Limited		Isode Limited
	5 Castle Business Village		5 Castle Business Village
	36 Station Road		36 Station Road
	Hampton, Middlesex TW12 2BX		Hampton, Middlesex TW12 2BX
	UK		UK
	skipping to change at page 8, line 7 ¶		skipping to change at page 10, line 7 ¶
	Huawei Technologies		Huawei Technologies
	Bantian Longgang		Bantian Longgang
	Shenzhen, Guandong 518129		Shenzhen, Guandong 518129
	P.R China		P.R China
	Phone: +86 755 28780808		Phone: +86 755 28780808
	Email: sunqian@huawei.com		Email: sunqian@huawei.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 38 change blocks.
	74 lines changed or deleted		164 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/