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