Network Working Group A. Melnikov Internet-Draft Isode Limited Intended status: Standards Track H. Schulzrinne Expires: September 8, 2009 Columbia U. Q. Sun Huawei Technologies March 7, 2009 Sieve Notification Mechanism: SIP MESSAGE draft-ietf-sieve-notify-sip-message-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 8, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the Melnikov, et al. Expires September 8, 2009 [Page 1] Internet-Draft Sieve Notification: SIP MESSAGE March 2009 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the SIP MESSAGE. Table of Contents 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Notify parameter "method" . . . . . . . . . . . . . . . . . . 3 3.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3 3.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . . 4 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4 3.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . . 4 3.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . . 4 3.7. Test notify_method_capability . . . . . . . . . . . . . . . . 5 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Requirements Conformance . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 Melnikov, et al. Expires September 8, 2009 [Page 2] Internet-Draft Sieve Notification: SIP MESSAGE March 2009 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 RFC 2119 [RFC2119]. 2. Introduction 2.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]). 2.2. Terminology This document inherits terminology from NOTIFY [NOTIFY], SIEVE [SIEVE], and RFC 3261 [SIP]. 3. Definition The SIP MESSAGE mechanism defined in this document results in the sending of a SIP MESSAGE request to notify a recipient about an email message. 3.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 included and MUST contain the value "MESSAGE". (Note that future specifications might extend this document and define Sieve notifications that use other SIP methods.) 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. 3.2. Notify tag ":from" The value of the ":from" tag MUST use the SIP "From" header field syntax; if the :from value is specified, has valid syntax, and is Melnikov, et al. Expires September 8, 2009 [Page 3] Internet-Draft Sieve Notification: SIP MESSAGE March 2009 valid according to the implementation-specific security checks (see Section 3.3 of [NOTIFY]), then the notification SHOULD include the "From" SIP header field containing the value of the :from notify tag. If the specified value is not valid, then it is ignored. 3.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. 3.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". 3.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. 3.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 Melnikov, et al. Expires September 8, 2009 [Page 4] Internet-Draft Sieve Notification: SIP MESSAGE March 2009 suggestion for retry in RFC 3261 [SIP]. 3.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.]] 4. 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;method=MESSAGE" 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 September 8, 2009 [Page 5] Internet-Draft Sieve Notification: SIP MESSAGE March 2009 notify :importance "1" :message "You got new mail!" "sip:romeo@example.com;method=MESSAGE?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! 5. 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: Need to compare this section with XMPP NOTIFY (RFC 5437) and Email NOTIFY (RFC 5436).]] 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 SHOULD include the Date header field containing the date-time of the moment when the SIP MESSAGE notification was generated. 5. The value of the Sieve ":from" tag SHOULD be transformed into the value of an SIP "From" header field, if it has valid syntax and is valid according to the implementation-specific security checks (see Section 3.3 of [NOTIFY]. If ":from" is not specified or is not valid, the SIP "From:" header field of the notification message SHOULD be set to the SIP address of the notification service associated with the SIEVE engine. Melnikov, et al. Expires September 8, 2009 [Page 6] Internet-Draft Sieve Notification: SIP MESSAGE March 2009 6. The value of the SIP "To" header field MUST be the SIP address specified in the SIP URI contained in the Sieve notify "method" parameter. 7. 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 3.6 for more details. 8. An implementation MUST NOT include any other extraneous information not specified in parameters to the notify action. 9. The notify_method_capability test for the "online" notification- capability behaves as described in Section 3.7. 6. Security Considerations [[anchor16: 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. 7. 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: SIP/SIPS as specified in 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 . Melnikov, et al. Expires September 8, 2009 [Page 7] Internet-Draft Sieve Notification: SIP MESSAGE March 2009 8. Acknowledgements This document borrows some text from draft-ietf-sieve-notify-xmpp. The authors would like to specially thank Adam Roach and Eric Burger for their helpful comments. 9. Normative References [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin, "Sieve Extension: Notifications", RFC 5435, January 2009. [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/ Melnikov, et al. Expires September 8, 2009 [Page 8] Internet-Draft Sieve Notification: SIP MESSAGE March 2009 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 Qian Sun Huawei Technologies Bantian Longgang Shenzhen, Guandong 518129 P.R China Phone: +86 755 28780808 Email: sunqian@huawei.com Melnikov, et al. Expires September 8, 2009 [Page 9]