idnits 2.17.1 draft-ietf-sieve-notify-sip-message-02.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2010) is 5044 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: 'RFC3261' is mentioned on line 192, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 320, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track H. Schulzrinne 5 Expires: January 4, 2011 Columbia U. 6 Q. Sun 7 Huawei Technologies 8 July 3, 2010 10 Sieve Notification Mechanism: SIP MESSAGE 11 draft-ietf-sieve-notify-sip-message-02 13 Abstract 15 This document describes a profile of the Sieve extension for 16 notifications, to allow notifications to be sent over the SIP 17 MESSAGE. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 4, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3.1. Notify parameter "method" . . . . . . . . . . . . . . . . . . 3 73 3.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3 74 3.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . . 4 75 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4 76 3.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . . 4 77 3.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . . 4 78 3.7. Test notify_method_capability . . . . . . . . . . . . . . . . 5 80 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 5. Requirements Conformance . . . . . . . . . . . . . . . . . . 6 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 90 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 94 1. Conventions Used in this Document 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 2. Introduction 102 2.1. Overview 104 The NOTIFY [NOTIFY] extension to the SIEVE [SIEVE] mail filtering 105 language is a framework for providing notifications by employing URIs 106 to specify the notification mechanism. This document defines how SIP 107 URIs (see RFC 3261 [SIP]) are used to generate notifications via the 108 SIP MESSAGE (see RFC 3428 [RFC3428]). 110 2.2. Terminology 112 This document inherits terminology from NOTIFY [NOTIFY], SIEVE 113 [SIEVE], and RFC 3261 [SIP]. 115 3. Definition 117 The SIP MESSAGE mechanism defined in this document results in the 118 sending of a SIP MESSAGE request to notify a recipient about an email 119 message. 121 3.1. Notify parameter "method" 123 The "method" parameter MUST be a URI that conforms to the SIP (or 124 SIPS) URI scheme (as specified in RFC 3261 [SIP]) and that identifies 125 a SIP (or SIPS) recipient of the notification. The URI MAY include 126 the resource identifier portion of a SIP address and URI parameters. 127 The URI parameter "method" MUST be included and MUST contain the 128 value "MESSAGE". (Note that future specifications might extend this 129 document and define Sieve notifications that use other SIP methods.) 130 The processing application MUST extract a SIP address from the URI in 131 accordance with the processing rules specified in RFC 3261 [SIP]. 132 The resulting SIP address MUST be encapsulated in SIP URI syntax as 133 Request-URI and the value of the "To" header field of the SIP MESSAGE 134 request. 136 3.2. Notify tag ":from" 138 The value of the ":from" tag MUST use the SIP "From" header field 139 syntax; if the :from value is specified, has valid syntax, and is 140 valid according to the implementation-specific security checks (see 141 Section 3.3 of [NOTIFY]), then the notification SHOULD include the 142 "From" SIP header field containing the value of the :from notify tag. 143 If the specified value is not valid, then it is ignored. 145 3.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 3.4. Notify tag ":importance" 153 The value of the ":importance" tag MAY be transformed into SIP 154 "Priority" header field (in addition to or instead of including in 155 the default message); if specified, the value of the "Priority" 156 header field MUST be "urgent" if the value of the ":importance" tag 157 is "1", "normal" if the value of the ":importance" tag is "2", or 158 "non-urgent" if the value of the ":importance" tag is "3". 160 3.5. Notify tag ":message" 162 If included, the ":message" tag MUST be transformed into the message- 163 body of a SIP MESSAGE, which MUST have Content-Type value of "text/ 164 plain" with CHARSET="UTF-8". [[anchor10: Should application/ 165 sieve-notification+xml Content type from draft-mahy-sieve-notify-sip 166 be used instead?]] If not included, the default message body SHOULD 167 contain values of the "From" and "Subject" header fields of the 168 triggering email message (and MAY include the value of the 169 ":importance" tag, if one is specified), as shown in one of the 170 examples below. 172 3.6. Other Definitions 174 The value of the SIP "From" header field specified in the SIP 175 notification message MUST be the SIP address of the notification 176 service itself. 178 An implementation MUST ignore any URI parameter it does not 179 understand (i.e., the URI MUST be processed as if the parameter were 180 not present). It is RECOMMENDED not to use the hname "body" 181 parameter value as the message-body of the SIP MESSAGE request. If 182 hname "body" parameter and ":message" tag are present at the same 183 time, the "body" parameter MUST be ignored.[[anchor11: Any other SIP 184 URI parameters that should be used?]] 186 The policy of retry delivery of a notification is a matter of 187 implementation and is not specified herein. But it SHOULD follow the 188 suggestion for retry in RFC 3261 [SIP].[[anchor12: Is this correct? 189 When one would possibly want to violate suggestions from RFC 3261? 190 If this is not correct, then the paragraph should read instead: The 191 policy of retry delivery of a notification is specified in 192 [RFC3261].]] 194 3.7. Test notify_method_capability 196 The notify_method_capability test for "online" may return "yes" or 197 "no" only if the Sieve processor can determine with certainty whether 198 or not the recipient of the notification message is can receive the 199 notification immediately. Otherwise, the test returns "maybe" for 200 this notification method. [[anchor13: Add some specific details 201 regarding determining online status of the recipient.]] 203 4. Examples 205 In the following examples, the sender of the email has an address of 206 juliet@example.org, the entity to be notified has a SIP address of 207 , and the notification service has a SIP 208 address . 210 The following is a basic Sieve notify action with only a method: 212 notify "sip:romeo@example.com;method=MESSAGE" 214 The resulting SIP MESSAGE request might be as follows: 216 MESSAGE sip:romeo@example.com SIP/2.0 217 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 218 Max-Forwards: 70 219 From: sip:notifier@example.com;tag=32328 220 To: sip:romeo@example.com 221 Call-ID: asd88asd77a@1.2.3.4 222 CSeq: 1 MESSAGE 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 The following is a more advanced Sieve notify action with a method, 232 importance, subject, and message: 234 notify :importance "1" 235 :message "You got new mail!" 236 "sip:romeo@example.com;method=MESSAGE?subject=SIEVE" 238 MESSAGE sip:romeo@example.com SIP/2.0 239 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 240 Max-Forwards: 70 241 From: sip:notifier@example.com;tag=32328 242 To: sip:romeo@example.com 243 Subject: SIEVE 244 Priority: urgent 245 Call-ID: asd88asd77a@1.2.3.4 246 CSeq: 1 MESSAGE 247 Content-Type: text/plain 248 Content-Length: 19 250 You got new mail! 252 5. Requirements Conformance 254 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve 255 notification methods. The conformance of the SIP MESSAGE 256 notification mechanism is provided here.[[anchor16: Need to compare 257 this section with XMPP NOTIFY (RFC 5437) and Email NOTIFY (RFC 258 5436).]] 259 1. An implementation of the SIP MESSAGE notification method SHOULD 260 NOT modify the final notification text (e.g., to limit the 261 length); however, a given deployment MAY do so. Modification of 262 characters themselves should not be necessary, since SIP MESSAGE 263 body is encoded in UTF-8 [RFC3629]. 264 2. An implementation MAY ignore parameters specified in the 265 ":importance", and ":options" tags. 266 3. If not included, the default message body SHOULD contain values 267 of the "From" and "Subject" header fields of the triggering email 268 message (and MAY include the value of the ":importance" tag, if 269 one is specified), as shown in one of the examples below. 270 4. A notification sent via the SIP MESSAGE notification method 271 SHOULD include the Date header field containing the date-time of 272 the moment when the SIP MESSAGE notification was generated. 273 5. The value of the Sieve ":from" tag SHOULD be transformed into the 274 value of an SIP "From" header field, if it has valid syntax and 275 is valid according to the implementation-specific security checks 276 (see Section 3.3 of [NOTIFY]. If ":from" is not specified or is 277 not valid, the SIP "From:" header field of the notification 278 message SHOULD be set to the SIP address of the notification 279 service associated with the SIEVE engine. 281 6. The value of the SIP "To" header field MUST be the SIP address 282 specified in the SIP URI contained in the Sieve notify "method" 283 parameter. 284 7. An implementation MUST ignore any URI parameters it does not 285 understand (i.e., the URI MUST be processed as if the action or 286 parameter were not present). See Section 3.6 for more details. 287 8. An implementation MUST NOT include any other extraneous 288 information not specified in parameters to the notify action. 289 9. The notify_method_capability test for the "online" notification- 290 capability behaves as described in Section 3.7. 292 6. Security Considerations 294 [[anchor17: TBD]] 296 Depending on the information included, sending a notification can be 297 comparable to forwarding mail to the notification recipient. Care 298 must be taken when forwarding mail automatically, to ensure that 299 confidential information is not sent into an insecure environment or 300 over an insecure channel. 302 UAs that support the MESSAGE request MUST implement end-to-end 303 authentication, body integrity, and body confidentiality mechanisms. 305 Other security considerations given in [NOTIFY], [SIEVE] and [SIP] 306 are also relevant to this document. 308 7. IANA Considerations 310 The following template provides the IANA registration of the Sieve 311 notification mechanism specified in this document: 313 To: iana@iana.org 314 Subject: Registration of new Sieve notification mechanism 315 Mechanism name: sip-message 316 Mechanism URI: SIP/SIPS as specified in RFC 3261 [SIP] 317 Mechanism-specific options: none 318 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 319 Person and email address to contact for further information: 320 See authors of [RFC XXXX] 322 This information should be added to the list of Sieve notification 323 mechanisms maintained at 324 . 326 8. Acknowledgements 328 This document borrows some text from draft-ietf-sieve-notify-xmpp. 330 The authors would like to specially thank Adam Roach and Eric Burger 331 for their helpful comments. 333 9. Normative References 335 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 336 Martin, "Sieve Extension: Notifications", RFC 5435, 337 January 2009. 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", RFC 2119, BCP 14, March 1997. 342 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 343 and D. Gurle, "Session Initiation Protocol (SIP) Extension 344 for Instant Messaging", RFC 3428, December 2002. 346 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 347 10646", STD 63, RFC 3629, November 2003. 349 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 350 Filtering Language", RFC 5228, January 2008. 352 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 353 A., Peterson, J., Sparks, R., Handley, M., and E. 354 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 355 June 2002. 357 Authors' Addresses 359 Alexey Melnikov 360 Isode Limited 361 5 Castle Business Village 362 36 Station Road 363 Hampton, Middlesex TW12 2BX 364 UK 366 Email: Alexey.Melnikov@isode.com 367 URI: http://www.melnikov.ca/ 368 Henning Schulzrinne 369 Columbia U. 370 Columbia University Department of Computer Science 371 New York, NY 10027 372 US 374 Phone: +1 212 939 7004 375 Email: hgs@cs.columbia.edu 377 Qian Sun 378 Huawei Technologies 379 Bantian Longgang 380 Shenzhen, Guandong 518129 381 P.R China 383 Phone: +86 755 28780808 384 Email: sunqian@huawei.com