idnits 2.17.1 draft-ietf-sieve-notify-sip-message-06.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 (October 4, 2011) is 4588 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 366, 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: April 6, 2012 B. Leiba 6 K. Li 7 Huawei Technologies 8 October 4, 2011 10 Sieve Notification Mechanism: SIP MESSAGE 11 draft-ietf-sieve-notify-sip-message-06 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 April 6, 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 . . . . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 1.1. Overview 87 The Notify extension [RFC5435] to the Sieve mail filtering language 88 [RFC5228] is a framework for providing notifications by employing 89 URIs that specify the notification mechanism. This document defines 90 how Session Initiation Protocol (SIP) URIs RFC 3261 [RFC3261] are 91 used to generate notifications via SIP MESSAGE RFC 3428 [RFC3428]. 93 1.2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 This document inherits terminology from the Sieve email filtering 100 language [RFC5228], the Sieve Notify extension [RFC5435], and RFC 101 3261 [RFC3261]. 103 2. Definition 105 The SIP MESSAGE mechanism defined in this document results in the 106 sending of a SIP MESSAGE request to notify a recipient about an email 107 message. 109 2.1. Notify parameter "method" 111 The "method" parameter MUST be a URI that conforms to the SIP or SIPS 112 URI scheme (as specified in RFC 3261 [RFC3261]) and that identifies a 113 SIP or SIPS recipient of the notification. The URI MAY include the 114 resource identifier portion of a SIP address and URI parameters. The 115 URI parameter "method" MUST be included and MUST contain the value 116 "MESSAGE". (Note that future specifications might extend this 117 document and define Sieve notifications that use other SIP methods.) 118 The processing application MUST form a request according to the rules 119 specified in RFC 3261 [RFC3261]. 121 Note that other URI schemes can also trigger SIP processing, but only 122 SIP and SIPS are defined here. Future extensions might define other 123 notification methods using SIP, using other URI schemes. 125 2.2. Notify tag ":from" 127 The value of the ":from" tag MUST use the SIP "From" header field 128 syntax; if the :from value is specified, has valid syntax, and is 129 valid according to the implementation-specific security checks (see 130 Section 3.3 of Sieve Notify [RFC5435]), then the notification SHOULD 131 include the "From" SIP header field containing the value of the :from 132 notify tag. If the specified value is not valid, then it is ignored. 134 All SIP authentication, including challenges and client certificates, 135 SHOULD be done in the context of the Sieve engine -- the Sieve engine 136 is the identity being authenticated. This avoids security issues 137 associated with the Sieve engine's having access to the end user's 138 SIP authentication credentials. The Sieve engine MAY use server-wide 139 credentials (including applicable certificates) that are the same for 140 all scripts. Alternatively, it MAY, for auditing purposes, use 141 different sets of Sieve-engine credentials when operating on behalf 142 of different users. 144 See section 22 of RFC 3261 [RFC3261] for more information about SIP 145 authentication. 147 2.3. Notify tag ":options" 149 Handling of the ":options" tag is implementation specific. This 150 document doesn't require presence of any option and doesn't define 151 how options are processed. 153 2.4. Notify tag ":importance" 155 The ":importance" tag is intended to convey the importance of the SIP 156 MESSAGE notification, not the importance of the email message that 157 generated the notification. The value of the ":importance" tag MAY, 158 therefore, be transformed into SIP "Priority" header field (in 159 addition to or instead of including it in the body of the message). 160 Note that because the Sieve ":importance" tag only has three values, 161 not all SIP "Priority" values can be represented in the 162 transformation. If this transformation is done, the value of the 163 "Priority" header field MUST be "urgent" if the value of the 164 ":importance" tag is "1", "normal" if the value of the ":importance" 165 tag is "2", and "non-urgent" if the value of the ":importance" tag is 166 "3". There is no mapping to the SIP value "emergency", nor to any 167 additional values that might be defined. 169 2.5. Notify tag ":message" 171 If the ":message" tag is included, it MUST be transformed into the 172 message-body of a SIP MESSAGE, which MUST have Content-Type value of 173 "text/plain" with CHARSET="UTF-8". If the ":message" tag is not 174 included, a default message will be used. The default message body 175 SHOULD contain the values of the "From" and "Subject" header fields 176 of the triggering email message (and MAY include the value of the 177 ":importance" tag, if one is specified), as shown in Section 3.2 178 below. 180 Note that in no case is the actual triggering message body included 181 in the notification. 183 Implementations MUST comply with the SIP MESSAGE size limits, as 184 discussed in section 8 of RFC 3428 [RFC3428]. 186 2.6. Other Definitions 188 An implementation MUST ignore any URI parameter it does not 189 understand (the URI MUST be processed as if the parameter were not 190 present). Implementations SHOULD NOT use the hname "body" parameter 191 value as the message-body of the SIP MESSAGE request. If the hname 192 "body" parameter and ":message" tag are present at the same time, the 193 "body" parameter MUST be ignored. 195 If the notification request fails, there will be a SIP error code 196 describing the failure. The policy for retrying delivery of failed 197 notifications is specified in RFC 3261 [RFC3261], according to the 198 error code. In other words, unlike the situation with some other 199 Sieve notification methods, retries for SIP MESSAGE notifications are 200 controlled by the notification protocol itself (SIP). 202 2.7. Test notify_method_capability 204 Because, absent use of SIP extensions such as [RFC3856], it is 205 impossible to tell in advance whether the notification recipient is 206 online and able to receive a SIP MESSAGE, the 207 notify_method_capability test for "online" will always return "maybe" 208 for this notification method. 210 3. Examples 212 In the following examples, the sender of the email has an address of 213 juliet@example.org, the entity to be notified has a SIP address of 214 , and the notification service has a SIP 215 address . 217 3.1. Example 1 219 The following is a basic Sieve notify action with only a method: 221 notify "sip:romeo@example.com;method=MESSAGE" 223 The resulting SIP MESSAGE request might be as follows: 225 MESSAGE sip:romeo@example.com SIP/2.0 226 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 227 Max-Forwards: 70 228 From: sip:notifier@example.com;tag=32328 229 To: sip:romeo@example.com 230 Call-ID: asd88asd77a@1.2.3.4 231 CSeq: 1 MESSAGE 232 Date: Sat, 13 Nov 2010 23:29:00 GMT 233 Content-Type: text/plain 234 Content-Length: 53 236 wrote: Contact me immediately! 238 In the example above the email message was received from 239 juliet@example.com and had "Subject: Contact me immediately!" 241 3.2. Example 2 243 The following is a more advanced Sieve notify action with a method, 244 importance, subject, and message: 246 notify :importance "1" 247 :message "You got new mail!" 248 "sip:romeo@example.com;method=MESSAGE?subject=SIEVE" 250 MESSAGE sip:romeo@example.com SIP/2.0 251 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 252 Max-Forwards: 70 253 From: sip:notifier@example.com;tag=32328 254 To: sip:romeo@example.com 255 Subject: SIEVE 256 Priority: urgent 257 Call-ID: asd88asd77a@1.2.3.4 258 CSeq: 1 MESSAGE 259 Date: Fri, 08 Apr 2011 06:54:00 GMT 260 Content-Type: text/plain 261 Content-Length: 19 263 You got new mail! 265 4. Requirements Conformance Checklist 267 Section 3.8 of Sieve Notify [RFC5435] specifies a set of requirements 268 for Sieve notification methods. A checklist is provided here to show 269 conformance of the SIP MESSAGE notification method. 271 1. No new Sieve tags have been added to the "notify" action. 273 2. An implementation of the SIP MESSAGE notification method SHOULD 274 NOT modify the final notification text, except to comply with 275 SIP MESSAGE length limits. Deployments MAY make operational 276 decisions about notification text, for reasons such as privacy 277 and confidentiality. Modification of characters themselves 278 should not be necessary, since the SIP MESSAGE body is encoded 279 in UTF-8 [RFC3629]. 281 3. An implementation MAY ignore parameters specified in the 282 ":importance", and ":options" tags. 284 4. A default message is suggested in Section 2.5. 286 5. A notification sent via the SIP MESSAGE notification method MAY 287 include the Date header field containing the date-time of the 288 moment when the SIP MESSAGE notification was generated. 290 6. The notification source is identified through the SIP "From:" 291 header field, via the Sieve Notify ":from" tag (see Section 2.2. 293 7. An implementation MUST NOT include any other extraneous 294 information not specified in parameters to the notify action. 296 8. An implementation MUST ignore any URI parameters it does not 297 understand (i.e., the URI MUST be processed as if the action or 298 parameter were not present). See Section 2.6 for more details. 300 9. The notify_method_capability test for the "online" notification- 301 capability behaves as described in Section 2.7. 303 10. The policy for retrying delivery of failed notifications is 304 specified in RFC 3261 [RFC3261], as noted in Section 2.6. 306 5. Security Considerations 308 Depending on the information included, sending a notification can be, 309 from a confidentiality point of view, comparable to forwarding mail 310 to the notification recipient. Care must be taken when automatically 311 forwarding information such as the sender and the subject of a 312 message, to ensure that confidential information is not sent into an 313 insecure environment or over an insecure channel. Depending upon the 314 environment, this might entail using SIPS URIs, not sending 315 information about the subject and/or the sender, or applying 316 heuristics to the message to determine what may be sent. 318 As required by RFC 3428, user agents that support the SIP MESSAGE 319 request MUST implement end-to-end authentication, body integrity, and 320 body confidentiality mechanisms. At the time of this writing, there 321 is not widespread deployment of SIP end-to-end security, so there can 322 be cases where it is not possible to use it, even though it is 323 implemented on one end. Its important to note that such situations 324 are open to exposure of user credentials, message content, and other 325 private information via man-in-the-middle and other passive attacks. 327 The Sieve Notify extension specifies that notification methods MUST 328 provide mechanisms for avoiding notification loops. In this case, 329 the SIP protocol itself prevents loops, and no explicit work is 330 needed within the notification mechanism. In situations where a SIP 331 MESSAGE notification can result in an email message, which could 332 generate another SIP MESSAGE notification, loop prevention through 333 rate detection and limiting might be necessary. An implementation 334 might detect too many notifications within a given time period, too 335 many triggered by a particular sender, too many with the same 336 subject, or the like, and shut off the affected notifications for a 337 period of time or until manual intervention turns them back on. 339 If SIP MESSAGE requests might be billed by the message, or the use of 340 them might deplete a user's quota of messages, notification by this 341 mechanism can present a situation where someone using a large number 342 of messages to generate a large number of notifications will cause a 343 significant expense to the recipient. Because there is no external 344 way an attacker can tell that this is the case, such an attack would 345 likely be a random or nuisance attack. Nevertheless, users might be 346 warned of potential costs when they set up SIP MESSAGE notifications. 348 Other security considerations given in the Sieve base specification 349 [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 350 [RFC3261] are also relevant to this document. 352 6. IANA Considerations 354 The following template provides the IANA registration of the Sieve 355 notification mechanism specified in this document. This information 356 should be added to the list of Sieve notification mechanisms 357 maintained at . 359 To: iana@iana.org 360 Subject: Registration of new Sieve notification mechanism 361 Mechanism name: sip-message 362 Mechanism URI: SIP/SIPS as specified in RFC 3261 [RFC3261] 363 Mechanism-specific options: none 364 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 365 Person and email address to contact for further information: 366 See authors of [RFC XXXX] 368 7. Acknowledgements 370 This document borrows some text from draft-ietf-sieve-notify-xmpp 371 [RFC5437]. 373 Henning Schulzrinne (hgs@cs.columbia.edu) was a special contributor 374 to this document, with early work and reviews. 376 The authors would like to thank Adam Roach and Eric Burger for their 377 helpful comments. Ben Campbell did a very thorough RAI-team review, 378 as well as a follow-up review to make sure we resolved all of his 379 issues satisfactorily. This document was greatly improved by their 380 input. 382 8. References 384 8.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 390 A., Peterson, J., Sparks, R., Handley, M., and E. 391 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 392 June 2002. 394 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 395 and D. Gurle, "Session Initiation Protocol (SIP) Extension 396 for Instant Messaging", RFC 3428, December 2002. 398 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 399 10646", STD 63, RFC 3629, November 2003. 401 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 402 Language", RFC 5228, January 2008. 404 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 405 "Sieve Email Filtering: Extension for Notifications", 406 RFC 5435, January 2009. 408 8.2. Informative References 410 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 411 Initiation Protocol (SIP)", RFC 3856, August 2004. 413 [RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification 414 Mechanism: Extensible Messaging and Presence Protocol 415 (XMPP)", RFC 5437, January 2009. 417 Authors' Addresses 419 Alexey Melnikov 420 Isode Limited 421 5 Castle Business Village 422 36 Station Road 423 Hampton, Middlesex TW12 2BX 424 UK 426 Email: Alexey.Melnikov@isode.com 427 URI: http://www.melnikov.ca/ 429 Qian Sun 430 Huawei Technologies 431 Bantian, Longgang 432 Shenzhen, Guandong 518129 433 P.R China 435 Phone: +86 755 28780808 436 Email: sunqian@huawei.com 438 Barry Leiba 439 Huawei Technologies 441 Phone: +1 646 827 0648 442 Email: barryleiba@computer.org 443 URI: http://internetmessagingtechnology.org/ 444 Kepeng Li 445 Huawei Technologies 446 Huawei Base, Bantian, Longgang District 447 Shenzhen, Guangdong 518129 448 P. R. China 450 Phone: +86-755-28974289 451 Email: likepeng@huawei.com