idnits 2.17.1 draft-ietf-sieve-notify-sip-message-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (March 7, 2009) is 5528 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 316, but not defined Summary: 1 error (**), 0 flaws (~~), 3 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: September 8, 2009 Columbia U. 6 Q. Sun 7 Huawei Technologies 8 March 7, 2009 10 Sieve Notification Mechanism: SIP MESSAGE 11 draft-ietf-sieve-notify-sip-message-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 8, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes a profile of the Sieve extension for 60 notifications, to allow notifications to be sent over the SIP 61 MESSAGE. 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]. 190 3.7. Test notify_method_capability 192 The notify_method_capability test for "online" may return "yes" or 193 "no" only if the Sieve processor can determine with certainty whether 194 or not the recipient of the notification message is can receive the 195 notification immediately. Otherwise, the test returns "maybe" for 196 this notification method. [[anchor12: Add some specific details 197 regarding determining online status of the recipient.]] 199 4. Examples 201 In the following examples, the sender of the email has an address of 202 juliet@example.org, the entity to be notified has a SIP address of 203 , and the notification service has a SIP 204 address . 206 The following is a basic Sieve notify action with only a method: 208 notify "sip:romeo@example.com;method=MESSAGE" 210 The resulting SIP MESSAGE request might be as follows: 212 MESSAGE sip:romeo@example.com SIP/2.0 213 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 214 Max-Forwards: 70 215 From: sip:notifier@example.com;tag=32328 216 To: sip:romeo@example.com 217 Call-ID: asd88asd77a@1.2.3.4 218 CSeq: 1 MESSAGE 219 Content-Type: text/plain 220 Content-Length: 53 222 wrote: Contact me immediately! 224 In the example above the email message was received from 225 juliet@example.com and had "Subject: Contact me immediately!" 227 The following is a more advanced Sieve notify action with a method, 228 importance, subject, and message: 230 notify :importance "1" 231 :message "You got new mail!" 232 "sip:romeo@example.com;method=MESSAGE?subject=SIEVE" 234 MESSAGE sip:romeo@example.com SIP/2.0 235 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 236 Max-Forwards: 70 237 From: sip:notifier@example.com;tag=32328 238 To: sip:romeo@example.com 239 Subject: SIEVE 240 Priority: urgent 241 Call-ID: asd88asd77a@1.2.3.4 242 CSeq: 1 MESSAGE 243 Content-Type: text/plain 244 Content-Length: 19 246 You got new mail! 248 5. Requirements Conformance 250 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve 251 notification methods. The conformance of the SIP MESSAGE 252 notification mechanism is provided here.[[anchor15: Need to compare 253 this section with XMPP NOTIFY (RFC 5437) and Email NOTIFY (RFC 254 5436).]] 255 1. An implementation of the SIP MESSAGE notification method SHOULD 256 NOT modify the final notification text (e.g., to limit the 257 length); however, a given deployment MAY do so. Modification of 258 characters themselves should not be necessary, since SIP MESSAGE 259 body is encoded in UTF-8 [RFC3629]. 260 2. An implementation MAY ignore parameters specified in the 261 ":importance", and ":options" tags. 262 3. If not included, the default message body SHOULD contain values 263 of the "From" and "Subject" header fields of the triggering email 264 message (and MAY include the value of the ":importance" tag, if 265 one is specified), as shown in one of the examples below. 266 4. A notification sent via the SIP MESSAGE notification method 267 SHOULD include the Date header field containing the date-time of 268 the moment when the SIP MESSAGE notification was generated. 269 5. The value of the Sieve ":from" tag SHOULD be transformed into the 270 value of an SIP "From" header field, if it has valid syntax and 271 is valid according to the implementation-specific security checks 272 (see Section 3.3 of [NOTIFY]. If ":from" is not specified or is 273 not valid, the SIP "From:" header field of the notification 274 message SHOULD be set to the SIP address of the notification 275 service associated with the SIEVE engine. 277 6. The value of the SIP "To" header field MUST be the SIP address 278 specified in the SIP URI contained in the Sieve notify "method" 279 parameter. 280 7. An implementation MUST ignore any URI parameters it does not 281 understand (i.e., the URI MUST be processed as if the action or 282 parameter were not present). See Section 3.6 for more details. 283 8. An implementation MUST NOT include any other extraneous 284 information not specified in parameters to the notify action. 285 9. The notify_method_capability test for the "online" notification- 286 capability behaves as described in Section 3.7. 288 6. Security Considerations 290 [[anchor16: TBD]] 292 Depending on the information included, sending a notification can be 293 comparable to forwarding mail to the notification recipient. Care 294 must be taken when forwarding mail automatically, to ensure that 295 confidential information is not sent into an insecure environment or 296 over an insecure channel. 298 UAs that support the MESSAGE request MUST implement end-to-end 299 authentication, body integrity, and body confidentiality mechanisms. 301 Other security considerations given in [NOTIFY], [SIEVE] and [SIP] 302 are also relevant to this document. 304 7. IANA Considerations 306 The following template provides the IANA registration of the Sieve 307 notification mechanism specified in this document: 309 To: iana@iana.org 310 Subject: Registration of new Sieve notification mechanism 311 Mechanism name: sip-message 312 Mechanism URI: SIP/SIPS as specified in RFC 3261 [SIP] 313 Mechanism-specific options: none 314 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 315 Person and email address to contact for further information: 316 See authors of [RFC XXXX] 318 This information should be added to the list of Sieve notification 319 mechanisms maintained at 320 . 322 8. Acknowledgements 324 This document borrows some text from draft-ietf-sieve-notify-xmpp. 326 The authors would like to specially thank Adam Roach and Eric Burger 327 for their helpful comments. 329 9. Normative References 331 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 332 Martin, "Sieve Extension: Notifications", RFC 5435, 333 January 2009. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", RFC 2119, BCP 14, March 1997. 338 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 339 and D. Gurle, "Session Initiation Protocol (SIP) Extension 340 for Instant Messaging", RFC 3428, December 2002. 342 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 343 10646", STD 63, RFC 3629, November 2003. 345 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 346 Filtering Language", RFC 5228, January 2008. 348 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 349 A., Peterson, J., Sparks, R., Handley, M., and E. 350 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 351 June 2002. 353 Authors' Addresses 355 Alexey Melnikov 356 Isode Limited 357 5 Castle Business Village 358 36 Station Road 359 Hampton, Middlesex TW12 2BX 360 UK 362 Email: Alexey.Melnikov@isode.com 363 URI: http://www.melnikov.ca/ 364 Henning Schulzrinne 365 Columbia U. 366 Columbia University Department of Computer Science 367 New York, NY 10027 368 US 370 Phone: +1 212 939 7004 371 Email: hgs@cs.columbia.edu 373 Qian Sun 374 Huawei Technologies 375 Bantian Longgang 376 Shenzhen, Guandong 518129 377 P.R China 379 Phone: +86 755 28780808 380 Email: sunqian@huawei.com