Network Working Group A. Melnikov Internet-Draft Isode Limited Intended status: Standards Track H. Schulzrinne Expires: August 20, 2008 Columbia U. Q. Sun Huawei Technologies February 17, 2008 Sieve Notification Mechanism: SIP MESSAGE draft-melnikov-sieve-notify-sip-message-01 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. This Internet-Draft will expire on August 20, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the SIP MESSAGE. Melnikov, et al. Expires August 20, 2008 [Page 1] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . . 3 2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3 2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 3 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 4 2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . 4 2.7. Test notify_method_capability . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements Conformance . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . 10 Melnikov, et al. Expires August 20, 2008 [Page 2] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 1. Introduction 1.1. Overview The NOTIFY [NOTIFY] extension to the SIEVE [SIEVE] mail filtering language is a framework for providing notifications by employing URIs to specify the notification mechanism. This document defines how SIP URIs (see RFC 3261 [SIP]) are used to generate notifications via the SIP MESSAGE (see RFC 3428 [RFC3428]). 1.2. Terminology This document inherits terminology from NOTIFY [NOTIFY], SIEVE [SIEVE], and RFC 3261 [SIP]. 2. Definition The sip message mechanism results in the sending of a SIP MESSAGE request to notify a recipient about an email message. 2.1. Notify parameter "method" The "method" parameter MUST be a URI that conforms to the SIP (or SIPS) URI scheme (as specified in RFC 3261 [SIP]) and that identifies a SIP (or SIPS) recipient of the notification. The URI MAY include the resource identifier portion of a SIP address and URI parameters. The URI parameter "method" MUST be ignored, because only the MESSAGE method is allowed by this specification. The processing application MUST extract a SIP address from the URI in accordance with the processing rules specified in RFC 3261 [SIP]. The resulting SIP address MUST be encapsulated in SIP URI syntax as Request-URI and the value of the "To" header field of the SIP MESSAGE request. 2.2. Notify tag ":from" The value of the ":from" tag MUST use the SIP "Reply-To" syntax; if the :from value is specified and has valid syntax, the notification MUST include the "Reply-To" SIP header field containing the value of the :from notify tag. If the value has invalid syntax, this is considered a Sieve script processing error. [[anchor6: Should the value be ignored instead?]] 2.3. Notify tag ":options" 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. Melnikov, et al. Expires August 20, 2008 [Page 3] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 2.4. Notify tag ":importance" The value of the ":importance" tag MAY be transformed into SIP "Priority" header field (in addition to or instead of including in the default message); if specified, the value of the "Priority" 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 "non-urgent" if the value of the ":importance" tag is "3". 2.5. Notify tag ":message" If included, the ":message" tag MUST be transformed into the message- body of a SIP MESSAGE, which MUST have Content-Type value of "text/ plain" with CHARSET="UTF-8". [[anchor10: Should application/ 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 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 understand (i.e., the URI MUST be processed as if the parameter were not present). It is RECOMMENDED not to use the hname "body" parameter value as the message-body of the SIP MESSAGE request. If hname "body" parameter and ":message" tag are present at the same 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 implementation and is not specified herein. But it SHOULD follow the 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?]] Melnikov, et al. Expires August 20, 2008 [Page 4] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 3. Examples In the following examples, the sender of the email has an address of juliet@example.org, the entity to be notified has a SIP address of , and the notification service has a SIP address . The following is a basic Sieve notify action with only a method: notify "sip:romeo@example.com" The resulting SIP MESSAGE request might be as follows: MESSAGE sip:romeo@example.com SIP/2.0 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:notifier@example.com;tag=32328 To: sip:romeo@example.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 53 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, importance, subject, and message: Melnikov, et al. Expires August 20, 2008 [Page 5] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 notify :importance "1" :message "You got new mail!" "sip:romeo@example.com?subject=SIEVE" MESSAGE sip:romeo@example.com SIP/2.0 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:notifier@example.com;tag=32328 To: sip:romeo@example.com Subject: SIEVE Priority: urgent Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 19 You got new mail! 4. Requirements Conformance 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. Melnikov, et al. Expires August 20, 2008 [Page 6] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 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 [[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 authentication, body integrity, and body confidentiality mechanisms. Other security considerations given in [NOTIFY], [SIEVE] and [SIP] are also relevant to this document. 6. IANA Considerations The following template provides the IANA registration of the Sieve notification mechanism specified in this document: To: iana@iana.org Subject: Registration of new Sieve notification mechanism 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 . 7. Acknowledgements This document borrows some text from draft-ietf-sieve-notify-xmpp. Melnikov, et al. Expires August 20, 2008 [Page 7] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 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 Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 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 Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/ Henning Schulzrinne Columbia U. Columbia University Department of Computer Science New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs@cs.columbia.edu Melnikov, et al. Expires August 20, 2008 [Page 8] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 Qian Sun Huawei Technologies Bantian Longgang Shenzhen, Guandong 518129 P.R China Phone: +86 755 28780808 Email: sunqian@huawei.com Melnikov, et al. Expires August 20, 2008 [Page 9] Internet-Draft Sieve Notification: SIP MESSAGE February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 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@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Melnikov, et al. Expires August 20, 2008 [Page 10]