idnits 2.17.1 draft-ietf-sieve-notify-sip-message-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 7, 2011) is 4614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC XXXX' is mentioned on line 334, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track Q. Sun 5 Expires: March 10, 2012 B. Leiba 6 K. Li 7 Huawei Technologies 8 September 7, 2011 10 Sieve Notification Mechanism: SIP MESSAGE 11 draft-ietf-sieve-notify-sip-message-05 13 Abstract 15 This document describes a profile of the Sieve extension for 16 notifications, to allow notifications to be sent over SIP MESSAGE. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 10, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . . . 3 58 2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3 59 2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . . 4 60 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4 61 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . . 4 62 2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . . 5 63 2.7. Test notify_method_capability . . . . . . . . . . . . . . . . 5 65 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Requirements Conformance Checklist . . . . . . . . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 1.1. Overview 85 The Notify extension [RFC5435] to the Sieve mail filtering language 86 [RFC5228] is a framework for providing notifications by employing 87 URIs that specify the notification mechanism. This document defines 88 how SIP URIs RFC 3261 [RFC3261] are used to generate notifications 89 via SIP MESSAGE RFC 3428 [RFC3428]. 91 1.2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 This document inherits terminology from the Sieve email filtering 98 language [RFC5228], the Sieve Notify extension [RFC5435], and RFC 99 3261 [RFC3261]. 101 2. Definition 103 The SIP MESSAGE mechanism defined in this document results in the 104 sending of a SIP MESSAGE request to notify a recipient about an email 105 message. 107 2.1. Notify parameter "method" 109 The "method" parameter MUST be a URI that conforms to the SIP or SIPS 110 URI scheme (as specified in RFC 3261 [RFC3261]) and that identifies a 111 SIP or SIPS recipient of the notification. The URI MAY include the 112 resource identifier portion of a SIP address and URI parameters. The 113 URI parameter "method" MUST be included and MUST contain the value 114 "MESSAGE". (Note that future specifications might extend this 115 document and define Sieve notifications that use other SIP methods.) 116 The processing application MUST form a request according to the rules 117 specified in RFC 3261 [RFC3261]. 119 Note that other URI schemes can also trigger SIP processing, but only 120 SIP and SIPS are defined here. Future extensions might define other 121 notification methods using SIP, using other URI schemes. 123 2.2. Notify tag ":from" 125 The value of the ":from" tag MUST use the SIP "From" header field 126 syntax; if the :from value is specified, has valid syntax, and is 127 valid according to the implementation-specific security checks (see 128 Section 3.3 of Sieve Notify [RFC5435]), then the notification SHOULD 129 include the "From" SIP header field containing the value of the :from 130 notify tag. If the specified value is not valid, then it is ignored. 132 All SIP authentication, including challenges and client certificates, 133 SHOULD be done in the context of the Sieve engine -- the Sieve engine 134 is the identity being authenticated. This avoids security issues 135 associated with the Sieve engine's having access to the end user's 136 SIP authentication credentials. The Sieve engine MAY use server-wide 137 credentials (including applicable certificates) that are the same for 138 all scripts. Alternatively, it MAY, for auditing purposes, use 139 different sets of Sieve-engine credentials when operating on behalf 140 of different users. 142 See section 22 of RFC 3261 [RFC3261] for more information about SIP 143 authentication. 145 2.3. Notify tag ":options" 147 Handling of the ":options" tag is implementation specific. This 148 document doesn't require presence of any option and doesn't define 149 how options are processed. 151 2.4. Notify tag ":importance" 153 The ":importance" tag is intended to convey the importance of the SIP 154 MESSAGE notification, not the importance of the email message that 155 generated the notification. The value of the ":importance" tag MAY, 156 therefore, be transformed into SIP "Priority" header field (in 157 addition to or instead of including it in the body of the message). 158 If this is done, the value of the "Priority" header field MUST be 159 "urgent" if the value of the ":importance" tag is "1", "normal" if 160 the value of the ":importance" tag is "2", and "non-urgent" if the 161 value of the ":importance" tag is "3". 163 2.5. Notify tag ":message" 165 If the ":message" tag is included, it MUST be transformed into the 166 message-body of a SIP MESSAGE, which MUST have Content-Type value of 167 "text/plain" with CHARSET="UTF-8". If the ":message" tag is not 168 included, a default message will be used. The default message body 169 SHOULD contain the values of the "From" and "Subject" header fields 170 of the triggering email message (and MAY include the value of the 171 ":importance" tag, if one is specified), as shown in Section 3.2 172 below. 174 Implementations MUST comply with the SIP MESSAGE size limits, as 175 discussed in section 8 of RFC 3428 [RFC3428]. 177 2.6. Other Definitions 179 An implementation MUST ignore any URI parameter it does not 180 understand (the URI MUST be processed as if the parameter were not 181 present). Implementations SHOULD NOT use the hname "body" parameter 182 value as the message-body of the SIP MESSAGE request. If the hname 183 "body" parameter and ":message" tag are present at the same time, the 184 "body" parameter MUST be ignored. 186 If the notification request fails, there will be a SIP error code 187 describing the failure. The policy for retrying delivery of failed 188 notifications is specified in RFC 3261 [RFC3261], according to the 189 error code. In other words, unlike the situation with some other 190 Sieve notification methods, retries for SIP MESSAGE notifications are 191 controlled by the notification protocol itself (SIP). 193 2.7. Test notify_method_capability 195 Because it is impossible to tell in advance whether the notification 196 recipient is online and able to receive a SIP MESSAGE, the 197 notify_method_capability test for "online" will always return "maybe" 198 for this notification method. 200 3. Examples 202 In the following examples, the sender of the email has an address of 203 juliet@example.org, the entity to be notified has a SIP address of 204 , and the notification service has a SIP 205 address . 207 3.1. Example 1 209 The following is a basic Sieve notify action with only a method: 211 notify "sip:romeo@example.com;method=MESSAGE" 213 The resulting SIP MESSAGE request might be as follows: 215 MESSAGE sip:romeo@example.com SIP/2.0 216 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 217 Max-Forwards: 70 218 From: sip:notifier@example.com;tag=32328 219 To: sip:romeo@example.com 220 Call-ID: asd88asd77a@1.2.3.4 221 CSeq: 1 MESSAGE 222 Date: Sat, 13 Nov 2010 23:29:00 GMT 223 Content-Type: text/plain 224 Content-Length: 53 226 wrote: Contact me immediately! 228 In the example above the email message was received from 229 juliet@example.com and had "Subject: Contact me immediately!" 231 3.2. Example 2 233 The following is a more advanced Sieve notify action with a method, 234 importance, subject, and message: 236 notify :importance "1" 237 :message "You got new mail!" 238 "sip:romeo@example.com;method=MESSAGE?subject=SIEVE" 240 MESSAGE sip:romeo@example.com SIP/2.0 241 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 242 Max-Forwards: 70 243 From: sip:notifier@example.com;tag=32328 244 To: sip:romeo@example.com 245 Subject: SIEVE 246 Priority: urgent 247 Call-ID: asd88asd77a@1.2.3.4 248 CSeq: 1 MESSAGE 249 Date: Fri, 08 Apr 2011 06:54:00 GMT 250 Content-Type: text/plain 251 Content-Length: 19 253 You got new mail! 255 4. Requirements Conformance Checklist 257 Section 3.8 of Sieve Notify [RFC5435] specifies a set of requirements 258 for Sieve notification methods. A checklist is provided here to show 259 conformance of the SIP MESSAGE notification method. 261 1. No new Sieve tags have been added to the "notify" action. 263 2. An implementation of the SIP MESSAGE notification method SHOULD 264 NOT modify the final notification text, except to comply with 265 SIP MESSAGE length limits. Deployments MAY make operational 266 decisions about notification text, for reasons such as privacy 267 and confidentiality. Modification of characters themselves 268 should not be necessary, since the SIP MESSAGE body is encoded 269 in UTF-8 [RFC3629]. 271 3. An implementation MAY ignore parameters specified in the 272 ":importance", and ":options" tags. 274 4. A default message is suggested in Section 2.5. 276 5. A notification sent via the SIP MESSAGE notification method MAY 277 include the Date header field containing the date-time of the 278 moment when the SIP MESSAGE notification was generated. 280 6. The notification source is identified through the SIP "From:" 281 header field, via the Sieve Notify ":from" tag (see Section 2.2. 283 7. An implementation MUST NOT include any other extraneous 284 information not specified in parameters to the notify action. 286 8. An implementation MUST ignore any URI parameters it does not 287 understand (i.e., the URI MUST be processed as if the action or 288 parameter were not present). See Section 2.6 for more details. 290 9. The notify_method_capability test for the "online" notification- 291 capability behaves as described in Section 2.7. 293 10. The policy for retrying delivery of failed notifications is 294 specified in RFC 3261 [RFC3261], as noted in Section 2.6. 296 5. Security Considerations 298 Depending on the information included, sending a notification can be 299 comparable to forwarding mail to the notification recipient. Care 300 must be taken when forwarding mail automatically, to ensure that 301 confidential information is not sent into an insecure environment or 302 over an insecure channel. 304 User agents that support the SIP MESSAGE request MUST implement end- 305 to-end authentication, body integrity, and body confidentiality 306 mechanisms. 308 The Sieve Notify extension specifies that notification methods MUST 309 provide mechanisms for avoiding notification loops. In this case, 310 the SIP protocol itself prevents loops, and no explicit work is 311 needed within the notification mechanism. In situations where a SIP 312 MESSAGE notification can result in an email message, which could 313 generate another SIP MESSAGE notification, loop prevention through 314 rate limiting might be necessary. 316 Other security considerations given in the Sieve base specification 317 [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 318 [RFC3261] are also relevant to this document. 320 6. IANA Considerations 322 The following template provides the IANA registration of the Sieve 323 notification mechanism specified in this document. This information 324 should be added to the list of Sieve notification mechanisms 325 maintained at . 327 To: iana@iana.org 328 Subject: Registration of new Sieve notification mechanism 329 Mechanism name: sip-message 330 Mechanism URI: SIP/SIPS as specified in RFC 3261 [RFC3261] 331 Mechanism-specific options: none 332 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 333 Person and email address to contact for further information: 334 See authors of [RFC XXXX] 336 7. Acknowledgements 338 This document borrows some text from draft-ietf-sieve-notify-xmpp. 340 Henning Schulzrinne (hgs@cs.columbia.edu) was a special contributor 341 to this document, with early work and reviews. 343 The authors would like to thank Adam Roach and Eric Burger for their 344 helpful comments. Ben Campbell did a very thorough RAI-team review, 345 as well as a follow-up review to make sure we resolved all of his 346 issues satisfactorily. This document was greatly improved by their 347 input. 349 8. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 355 A., Peterson, J., Sparks, R., Handley, M., and E. 356 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 357 June 2002. 359 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 360 and D. Gurle, "Session Initiation Protocol (SIP) Extension 361 for Instant Messaging", RFC 3428, December 2002. 363 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 364 10646", STD 63, RFC 3629, November 2003. 366 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 367 Language", RFC 5228, January 2008. 369 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 370 "Sieve Email Filtering: Extension for Notifications", 371 RFC 5435, January 2009. 373 Authors' Addresses 375 Alexey Melnikov 376 Isode Limited 377 5 Castle Business Village 378 36 Station Road 379 Hampton, Middlesex TW12 2BX 380 UK 382 Email: Alexey.Melnikov@isode.com 383 URI: http://www.melnikov.ca/ 385 Qian Sun 386 Huawei Technologies 387 Bantian, Longgang 388 Shenzhen, Guandong 518129 389 P.R China 391 Phone: +86 755 28780808 392 Email: sunqian@huawei.com 393 Barry Leiba 394 Huawei Technologies 396 Phone: +1 646 827 0648 397 Email: barryleiba@computer.org 398 URI: http://internetmessagingtechnology.org/ 400 Kepeng Li 401 Huawei Technologies 402 Huawei Base, Bantian, Longgang District 403 Shenzhen, Guangdong 518129 404 P. R. China 406 Phone: +86-755-28974289 407 Email: likepeng@huawei.com