idnits 2.17.1 draft-ietf-sieve-notify-sip-message-04.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 (August 3, 2011) is 4642 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 336, 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 H. Schulzrinne 5 Expires: February 4, 2012 Columbia U. 6 Q. Sun 7 B. Leiba 8 K. Li 9 Huawei Technologies 10 August 3, 2011 12 Sieve Notification Mechanism: SIP MESSAGE 13 draft-ietf-sieve-notify-sip-message-04 15 Abstract 17 This document describes a profile of the Sieve extension for 18 notifications, to allow notifications to be sent over SIP MESSAGE. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 4, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . . . 3 60 2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3 61 2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . . 4 62 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4 63 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . . 4 64 2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . . 5 65 2.7. Test notify_method_capability . . . . . . . . . . . . . . . . 5 67 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Requirements Conformance Checklist . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 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 SIP URIs RFC 3261 [RFC3261] are used to generate notifications 91 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 If this is done, the value of the "Priority" header field MUST be 161 "urgent" if the value of the ":importance" tag is "1", "normal" if 162 the value of the ":importance" tag is "2", and "non-urgent" if the 163 value of the ":importance" tag is "3". 165 2.5. Notify tag ":message" 167 If the ":message" tag is included, it MUST be transformed into the 168 message-body of a SIP MESSAGE, which MUST have Content-Type value of 169 "text/plain" with CHARSET="UTF-8". If the ":message" tag is not 170 included, a default message will be used. The default message body 171 SHOULD contain the values of the "From" and "Subject" header fields 172 of the triggering email message (and MAY include the value of the 173 ":importance" tag, if one is specified), as shown in Section 3.2 174 below. 176 Implementations MUST comply with the SIP MESSAGE size limits, as 177 discussed in section 8 of RFC 3428 [RFC3428]. 179 2.6. Other Definitions 181 An implementation MUST ignore any URI parameter it does not 182 understand (the URI MUST be processed as if the parameter were not 183 present). Implementations SHOULD NOT use the hname "body" parameter 184 value as the message-body of the SIP MESSAGE request. If the hname 185 "body" parameter and ":message" tag are present at the same time, the 186 "body" parameter MUST be ignored. 188 If the notification request fails, there will be a SIP error code 189 describing the failure. The policy for retrying delivery of failed 190 notifications is specified in RFC 3261 [RFC3261], according to the 191 error code. In other words, unlike the situation with some other 192 Sieve notification methods, retries for SIP MESSAGE notifications are 193 controlled by the notification protocol itself (SIP). 195 2.7. Test notify_method_capability 197 Because it is impossible to tell in advance whether the notification 198 recipient is online and able to receive a SIP MESSAGE, the 199 notify_method_capability test for "online" will always return "maybe" 200 for this notification method. 202 3. Examples 204 In the following examples, the sender of the email has an address of 205 juliet@example.org, the entity to be notified has a SIP address of 206 , and the notification service has a SIP 207 address . 209 3.1. Example 1 211 The following is a basic Sieve notify action with only a method: 213 notify "sip:romeo@example.com;method=MESSAGE" 215 The resulting SIP MESSAGE request might be as follows: 217 MESSAGE sip:romeo@example.com SIP/2.0 218 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 219 Max-Forwards: 70 220 From: sip:notifier@example.com;tag=32328 221 To: sip:romeo@example.com 222 Call-ID: asd88asd77a@1.2.3.4 223 CSeq: 1 MESSAGE 224 Date: Sat, 13 Nov 2010 23:29:00 GMT 225 Content-Type: text/plain 226 Content-Length: 53 228 wrote: Contact me immediately! 230 In the example above the email message was received from 231 juliet@example.com and had "Subject: Contact me immediately!" 233 3.2. Example 2 235 The following is a more advanced Sieve notify action with a method, 236 importance, subject, and message: 238 notify :importance "1" 239 :message "You got new mail!" 240 "sip:romeo@example.com;method=MESSAGE?subject=SIEVE" 242 MESSAGE sip:romeo@example.com SIP/2.0 243 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 244 Max-Forwards: 70 245 From: sip:notifier@example.com;tag=32328 246 To: sip:romeo@example.com 247 Subject: SIEVE 248 Priority: urgent 249 Call-ID: asd88asd77a@1.2.3.4 250 CSeq: 1 MESSAGE 251 Date: Fri, 08 Apr 2011 06:54:00 GMT 252 Content-Type: text/plain 253 Content-Length: 19 255 You got new mail! 257 4. Requirements Conformance Checklist 259 Section 3.8 of Sieve Notify [RFC5435] specifies a set of requirements 260 for Sieve notification methods. A checklist is provided here to show 261 conformance of the SIP MESSAGE notification method. 263 1. No new Sieve tags have been added to the "notify" action. 265 2. An implementation of the SIP MESSAGE notification method SHOULD 266 NOT modify the final notification text, except to comply with 267 SIP MESSAGE length limits. Deployments MAY make operational 268 decisions about notification text, for reasons such as privacy 269 and confidentiality. Modification of characters themselves 270 should not be necessary, since the SIP MESSAGE body is encoded 271 in UTF-8 [RFC3629]. 273 3. An implementation MAY ignore parameters specified in the 274 ":importance", and ":options" tags. 276 4. A default message is suggested in Section 2.5. 278 5. A notification sent via the SIP MESSAGE notification method MAY 279 include the Date header field containing the date-time of the 280 moment when the SIP MESSAGE notification was generated. 282 6. The notification source is identified through the SIP "From:" 283 header field, via the Sieve Notify ":from" tag (see Section 2.2. 285 7. An implementation MUST NOT include any other extraneous 286 information not specified in parameters to the notify action. 288 8. An implementation MUST ignore any URI parameters it does not 289 understand (i.e., the URI MUST be processed as if the action or 290 parameter were not present). See Section 2.6 for more details. 292 9. The notify_method_capability test for the "online" notification- 293 capability behaves as described in Section 2.7. 295 10. The policy for retrying delivery of failed notifications is 296 specified in RFC 3261 [RFC3261], as noted in Section 2.6. 298 5. Security Considerations 300 Depending on the information included, sending a notification can be 301 comparable to forwarding mail to the notification recipient. Care 302 must be taken when forwarding mail automatically, to ensure that 303 confidential information is not sent into an insecure environment or 304 over an insecure channel. 306 User agents that support the SIP MESSAGE request MUST implement end- 307 to-end authentication, body integrity, and body confidentiality 308 mechanisms. 310 The Sieve Notify extension specifies that notification methods MUST 311 provide mechanisms for avoiding notification loops. In this case, 312 the SIP protocol itself prevents loops, and no explicit work is 313 needed within the notification mechanism. In situations where a SIP 314 MESSAGE notification can result in an email message, which could 315 generate another SIP MESSAGE notification, loop prevention through 316 rate limiting might be necessary. 318 Other security considerations given in the Sieve base specification 319 [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 320 [RFC3261] are also relevant to this document. 322 6. IANA Considerations 324 The following template provides the IANA registration of the Sieve 325 notification mechanism specified in this document. This information 326 should be added to the list of Sieve notification mechanisms 327 maintained at . 329 To: iana@iana.org 330 Subject: Registration of new Sieve notification mechanism 331 Mechanism name: sip-message 332 Mechanism URI: SIP/SIPS as specified in RFC 3261 [RFC3261] 333 Mechanism-specific options: none 334 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 335 Person and email address to contact for further information: 336 See authors of [RFC XXXX] 338 7. Acknowledgements 340 This document borrows some text from draft-ietf-sieve-notify-xmpp. 342 The authors would like to thank Adam Roach and Eric Burger for their 343 helpful comments. Ben Campbell did a very thorough RAI-team review, 344 as well as a follow-up review to make sure we resolved all of his 345 issues satisfactorily. This document was greatly improved by their 346 input. 348 8. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 354 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 Henning Schulzrinne 386 Columbia U. 387 Columbia University Department of Computer Science 388 New York, NY 10027 389 US 391 Phone: +1 212 939 7004 392 Email: hgs@cs.columbia.edu 393 Qian Sun 394 Huawei Technologies 395 Bantian, Longgang 396 Shenzhen, Guandong 518129 397 P.R China 399 Phone: +86 755 28780808 400 Email: sunqian@huawei.com 402 Barry Leiba 403 Huawei Technologies 405 Phone: +1 646 827 0648 406 Email: barryleiba@computer.org 407 URI: http://internetmessagingtechnology.org/ 409 Kepeng Li 410 Huawei Technologies 411 Huawei Base, Bantian, Longgang District 412 Shenzhen, Guangdong 518129 413 P. R. China 415 Phone: +86-755-28974289 416 Email: likepeng@huawei.com