idnits 2.17.1 draft-ietf-sieve-notify-sip-message-07.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 7, 2011) is 4585 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 377, 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 9, 2012 B. Leiba 6 K. Li 7 Huawei Technologies 8 October 7, 2011 10 Sieve Notification Mechanism: SIP MESSAGE 11 draft-ietf-sieve-notify-sip-message-07 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 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 default message body 183 SHOULD contain the values of the "From" and "Subject" header fields 184 of the triggering email message, because this information will be 185 useful to users receiving notifications (but see the Security 186 Considerations, Section 5). The default body might also include the 187 value of the ":importance" tag, if one is specified), as shown in 188 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). This specification prefers use of the ":message" tag over 201 the hname "body" parameter value as the message-body of the SIP 202 MESSAGE request. Implementations are advised to use ":message", and, 203 in particular, if the hname "body" parameter and ":message" tag are 204 present at the same time, the "body" parameter MUST be ignored. 206 The policy for retrying delivery of failed notifications is specified 207 in RFC 3261 [RFC3261], according to the SIP error code returned 208 during an attempt to deliver a SIP notification. In other words, 209 unlike the situation with some other Sieve notification methods, 210 retries for SIP MESSAGE notifications are controlled by the 211 notification protocol itself (SIP). 213 2.7. Test notify_method_capability 215 Absent use of SIP extensions such as [RFC3856], it is impossible to 216 tell in advance whether the notification recipient is online and able 217 to receive a SIP MESSAGE. Expect the notify_method_capability test 218 for "online" to frequently return "maybe" for this notification 219 method. 221 3. Examples 223 In the following examples, the sender of the email has an address of 224 juliet@example.org, the entity to be notified has a SIP address of 225 , and the notification service has a SIP 226 address . 228 3.1. Example 1 230 The following is a basic Sieve notify action with only a method: 232 notify "sip:romeo@example.com;method=MESSAGE" 234 The resulting SIP MESSAGE request might be as follows: 236 MESSAGE sip:romeo@example.com SIP/2.0 237 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 238 Max-Forwards: 70 239 From: sip:notifier@example.com;tag=32328 240 To: sip:romeo@example.com 241 Call-ID: asd88asd77a@1.2.3.4 242 CSeq: 1 MESSAGE 243 Date: Sat, 13 Nov 2010 23:29:00 GMT 244 Content-Type: text/plain 245 Content-Length: 53 247 wrote: Contact me immediately! 249 In the example above the email message was received from 250 juliet@example.com and had "Subject: Contact me immediately!" 252 3.2. Example 2 254 The following is a more advanced Sieve notify action with a method, 255 importance, subject, and message: 257 notify :importance "1" 258 :message "You got new mail!" 259 "sip:romeo@example.com;method=MESSAGE?subject=SIEVE" 261 MESSAGE sip:romeo@example.com SIP/2.0 262 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 263 Max-Forwards: 70 264 From: sip:notifier@example.com;tag=32328 265 To: sip:romeo@example.com 266 Subject: SIEVE 267 Priority: urgent 268 Call-ID: asd88asd77a@1.2.3.4 269 CSeq: 1 MESSAGE 270 Date: Fri, 08 Apr 2011 06:54:00 GMT 271 Content-Type: text/plain 272 Content-Length: 19 274 You got new mail! 276 4. Requirements Conformance Checklist 278 Section 3.8 of Sieve Notify [RFC5435] specifies a set of requirements 279 for Sieve notification methods. A checklist is provided here to show 280 conformance of the SIP MESSAGE notification method. 282 1. No new Sieve tags have been added to the "notify" action. 284 2. An implementation of the SIP MESSAGE notification method SHOULD 285 NOT modify the final notification text, except to comply with 286 SIP MESSAGE length limits. Deployments MAY make operational 287 decisions about notification text, for reasons such as privacy 288 and confidentiality. Modification of characters themselves 289 should not be necessary, since the SIP MESSAGE body is encoded 290 in UTF-8 [RFC3629]. 292 3. An implementation MAY ignore parameters specified in the 293 ":importance", and ":options" tags. 295 4. A default message is suggested in Section 2.5. 297 5. A notification sent via the SIP MESSAGE notification method MAY 298 include the Date header field containing the date-time of the 299 moment when the SIP MESSAGE notification was generated. 301 6. The notification source is identified through the SIP "From:" 302 header field, via the Sieve Notify ":from" tag (see Section 2.2. 304 7. An implementation MUST NOT include any other extraneous 305 information not specified in parameters to the notify action. 307 8. An implementation MUST ignore any URI parameters it does not 308 understand (i.e., the URI MUST be processed as if the action or 309 parameter were not present). See Section 2.6 for more details. 311 9. The notify_method_capability test for the "online" notification- 312 capability behaves as described in Section 2.7. 314 10. The policy for retrying delivery of failed notifications is 315 specified in RFC 3261 [RFC3261], as noted in Section 2.6. 317 5. Security Considerations 319 Depending on the information included, sending a notification can be, 320 from a confidentiality point of view, comparable to forwarding mail 321 to the notification recipient. Care must be taken when automatically 322 forwarding information such as the sender and the subject of a 323 message, to ensure that confidential information is not sent into an 324 insecure environment or over an insecure channel. Depending upon the 325 environment, this might entail using SIPS URIs, not sending 326 information about the subject and/or the sender, or applying 327 heuristics to the message to determine what may be sent. 329 As required by RFC 3428, user agents that support the SIP MESSAGE 330 request MUST implement end-to-end authentication, body integrity, and 331 body confidentiality mechanisms. At the time of this writing, there 332 is not widespread deployment of SIP end-to-end security, so there can 333 be cases where it is not possible to use it, even though it is 334 implemented on one end. Its important to note that such situations 335 are open to exposure of user credentials, message content, and other 336 private information via man-in-the-middle and other passive attacks. 338 The Sieve Notify extension specifies that notification methods MUST 339 provide mechanisms for avoiding notification loops. In this case, 340 the SIP protocol itself prevents loops, and no explicit work is 341 needed within the notification mechanism. In situations where a SIP 342 MESSAGE notification can result in an email message, which could 343 generate another SIP MESSAGE notification, loop prevention through 344 rate detection and limiting might be necessary. An implementation 345 might detect too many notifications within a given time period, too 346 many triggered by a particular sender, too many with the same 347 subject, or the like, and shut off the affected notifications for a 348 period of time or until manual intervention turns them back on. 350 If SIP MESSAGE requests might be billed by the message, or the use of 351 them might deplete a user's quota of messages, notification by this 352 mechanism can present a situation where someone using a large number 353 of messages to generate a large number of notifications will cause a 354 significant expense to the recipient. Because there is no external 355 way an attacker can tell that this is the case, such an attack would 356 likely be a random or nuisance attack. Nevertheless, users might be 357 warned of potential costs when they set up SIP MESSAGE notifications. 359 Other security considerations given in the Sieve base specification 360 [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 361 [RFC3261] are also relevant to this document. 363 6. IANA Considerations 365 The following template provides the IANA registration of the Sieve 366 notification mechanism specified in this document. This information 367 should be added to the list of Sieve notification mechanisms 368 maintained at . 370 To: iana@iana.org 371 Subject: Registration of new Sieve notification mechanism 372 Mechanism name: sip-message 373 Mechanism URI: SIP/SIPS as specified in RFC 3261 [RFC3261] 374 Mechanism-specific options: none 375 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 376 Person and email address to contact for further information: 377 See authors of [RFC XXXX] 379 7. Acknowledgements 381 This document borrows some text from draft-ietf-sieve-notify-xmpp 382 [RFC5437]. 384 Henning Schulzrinne (hgs@cs.columbia.edu) was a special contributor 385 to this document, with early work and reviews. 387 The authors would like to thank Adam Roach and Eric Burger for their 388 helpful comments. Ben Campbell did a very thorough RAI-team review, 389 as well as a follow-up review to make sure we resolved all of his 390 issues satisfactorily. This document was greatly improved by their 391 input. 393 8. References 394 8.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 400 A., Peterson, J., Sparks, R., Handley, M., and E. 401 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 402 June 2002. 404 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 405 and D. Gurle, "Session Initiation Protocol (SIP) Extension 406 for Instant Messaging", RFC 3428, December 2002. 408 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 409 10646", STD 63, RFC 3629, November 2003. 411 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 412 Language", RFC 5228, January 2008. 414 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 415 "Sieve Email Filtering: Extension for Notifications", 416 RFC 5435, January 2009. 418 8.2. Informative References 420 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 421 Initiation Protocol (SIP)", RFC 3856, August 2004. 423 [RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification 424 Mechanism: Extensible Messaging and Presence Protocol 425 (XMPP)", RFC 5437, January 2009. 427 Authors' Addresses 429 Alexey Melnikov 430 Isode Limited 431 5 Castle Business Village 432 36 Station Road 433 Hampton, Middlesex TW12 2BX 434 UK 436 Email: Alexey.Melnikov@isode.com 437 URI: http://www.melnikov.ca/ 438 Qian Sun 439 Huawei Technologies 440 Bantian, Longgang 441 Shenzhen, Guandong 518129 442 P.R China 444 Phone: +86 755 28780808 445 Email: sunqian@huawei.com 447 Barry Leiba 448 Huawei Technologies 450 Phone: +1 646 827 0648 451 Email: barryleiba@computer.org 452 URI: http://internetmessagingtechnology.org/ 454 Kepeng Li 455 Huawei Technologies 456 Huawei Base, Bantian, Longgang District 457 Shenzhen, Guangdong 518129 458 P. R. China 460 Phone: +86-755-28974289 461 Email: likepeng@huawei.com