idnits 2.17.1 draft-ietf-sieve-notify-sip-message-03.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 (July 8, 2011) is 4675 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 503, 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: January 9, 2012 Columbia U. 6 Q. Sun 7 B. Leiba 8 K. Li 9 Huawei Technologies 10 July 8, 2011 12 Sieve Notification Mechanism: SIP MESSAGE 13 draft-ietf-sieve-notify-sip-message-03 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 January 9, 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.1.1. Notify parameter "method" RAI review notes . . . . . . . . 4 61 2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . 7 63 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . 7 64 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . 7 65 2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . 8 66 2.7. Test notify_method_capability . . . . . . . . . . . . . . 8 68 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Requirements Conformance Checklist . . . . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 11 80 8. Normative References . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 1.1. Overview 88 The Notify extension [RFC5435] to the Sieve mail filtering language 89 [RFC5228] is a framework for providing notifications by employing 90 URIs that specify the notification mechanism. This document defines 91 how SIP URIs RFC 3261 [RFC3261] are used to generate notifications 92 via SIP MESSAGE RFC 3428 [RFC3428]. 94 [[REVIEW NOTES: Notes are placed below to document Adam Roach's RAI 95 review of the -00 version ( 96 http://www.ietf.org/mail-archive/web/rai/current/msg00345.html ) and 97 Ben Campbell's review of the -02 version ( 98 http://www.ietf.org/mail-archive/web/rai/current/msg00925.html )]] 100 1.2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 This document inherits terminology from the Sieve email filtering 107 language [RFC5228], the Sieve Notify extension [RFC5435], and RFC 108 3261 [RFC3261]. 110 2. Definition 112 The SIP MESSAGE mechanism defined in this document results in the 113 sending of a SIP MESSAGE request to notify a recipient about an email 114 message. 116 2.1. Notify parameter "method" 118 The "method" parameter MUST be a URI that conforms to the SIP (or 119 SIPS) URI scheme (as specified in RFC 3261 [RFC3261]) and that 120 identifies a SIP (or SIPS) recipient of the notification. The URI 121 MAY include the resource identifier portion of a SIP address and URI 122 parameters. The URI parameter "method" MUST be included and MUST 123 contain the value "MESSAGE". (Note that future specifications might 124 extend this document and define Sieve notifications that use other 125 SIP methods.) The processing application MUST form a request 126 according to the rules specified in RFC 3261 [RFC3261]. 128 [[BEN'S REVIEW, MINOR 1; ** resolved **: I think you've got the right 129 idea here, but the terminology is wrong--I.e. the SIP URI _is_ the 130 SIP address. I think what you are after is something more along the 131 lines of forming a SIP Request based on an "external" URI, similarly 132 to what you might do with a URI in a hypertext link or on a business 133 card. I suggest merely saying something along the lines of "form a 134 SIP request according to the rules in rfc 3261"]] 136 2.1.1. Notify parameter "method" RAI review notes 138 [[RAI REVIEW NOTES: This section and its subsections are included for 139 editing purposes, and will be removed before the document is final, 140 when the issues are resolved.]] 142 2.1.1.1. RAI review notes from Adam Roach 144 [[ADAM'S REVIEW 1: These are the notes on section 2.1 from Adam 145 Roach's review of 9 Jan 2009.]] 147 My first area of concern is that, while this seems a reasonable way 148 to perform this functionality in SIP, I don't think it's the only 149 reasonable way to do it in SIP. Consequently, this document needs to 150 take care not to preclude future SIP mechanisms for SIEVE 151 notifications. For example, the conveyance of more semantic 152 information in a PUBLISH message would be quite useful when there is 153 a dynamically changing community of parties interested in receiving 154 notifications. (The PUBLISH would be sent to an event agent, which 155 could then receive SUBSCRIBE requests from interested parties). This 156 may be applicable, for example, when monitoring shared resources, 157 such as technical support email queues. 159 However, the draft makes an implicit assumption that any SIEVE 160 notification method URI starting with "sip:" necessarily will make 161 use of the mechanism it defines, and never any other. There is no 162 means for disambiguating among multiple mechanisms. In fact, the 163 draft seems to go out of its way to ruin an extensibility mechanism 164 that it would have automatically inherited from SIP: "The URI 165 parameter 'method' MUST be ignored, because only the MESSAGE method 166 is allowed by this specification." 168 I would suggest that the draft be amended to either *require* a 169 "method" URI parameter (with "MESSAGE" indicating the mechanism 170 described in this document), or to include additional information in 171 the ":options" tag that explicitly indicates the use of this 172 document's mechanism. 174 2.1.1.2. RAI review notes from Ben Campbell 176 [[BEN'S REVIEW, MAJOR 1a: These are the notes on section 2.1 from Ben 177 Campbell's review of 1 Sep 2010.]] 178 You limit the method parameter to SIP or SIPS URIs. I can imagine 179 several reasons you might have done this, most likely to cut down on 180 the number of URIs that could would indicate the SIEVE rule was for 181 SIP. But there are other perfectly legitimate URI types for SIP 182 MESSAGE requests. For example TEL URIs are fairly common. IM URIs 183 are also legal for SIP MESSAGE, although you're not likely to see 184 those in the wild--but that could change in the future. SIP may add 185 new legal URI types in the future. 187 One way around this would be to have some other part of the notify 188 "method" parameter identify the fact that a SIP MESSAGE request is 189 intended, and then allow any URI type that is legal for SIP MESSAGE. 191 You also include the SIP URI method=parameter for the sake of 192 extensibility. This would be an issue if you allowed other URI 193 types, since the method parameter is not necessarily defined for all 194 URI types. I'm also not sure this gives you the extensibility you 195 want--you would not be able to do anything useful with "method=FOO" 196 without some additional SIEVE spec on how to send SIP FOO requests. 197 I think you would be better off leaving off the method URI parameter, 198 and instead encode something in the :options parameter. 200 [Note: I assume you added the method parameter based on feedback from 201 Adam from a while back. I note that he suggested using either the 202 method parameter, or something in :options. I am not disagreeing 203 with him--I'm just suggesting that the :options approach is the 204 better choice.] 206 2.1.1.3. Editor responses to RAI reviews 208 [[EDITOR NOTES TO RAI REVIEWS: These are the editor's responses, to 209 note work that still needs to be done.]] 211 Both of these reviews bring up the same issue: we painted ourselves 212 into a corner when we designed the Sieve Notify framework [RFC5435] 213 in the first place, by making the "method" parameter a URI, and 214 having the URI be the only way to distinguish the notification 215 method. That means that the Sieve engine needs to be able to take a 216 URI and know how to process it, and it also means that there's no way 217 to use the same URI for different notification methods, depending 218 upon the situation. 220 One problem with that is that we can't use "mailto:joe@example.org" 221 for any notification mechanism other than email, even if some other 222 notification mechanism keys off of an email address, and that if we 223 use a "tel:" URI for SIP, we can't use "tel:" URIs for anything else. 225 Another problem is that we have to know, in advance, all the URI 226 schemas that apply to a given notification method. 228 I don't know how to resolve these issues within the Sieve Notify 229 framework. (Barry) 231 2.2. Notify tag ":from" 233 The value of the ":from" tag MUST use the SIP "From" header field 234 syntax; if the :from value is specified, has valid syntax, and is 235 valid according to the implementation-specific security checks (see 236 Section 3.3 of Sieve Notify [RFC5435]), then the notification SHOULD 237 include the "From" SIP header field containing the value of the :from 238 notify tag. If the specified value is not valid, then it is ignored. 240 All SIP authentication, including challenges and client certificates, 241 SHOULD be done in the context of the Sieve engine -- the Sieve engine 242 is the identity being authenticated. This avoids security issues 243 associated with the Sieve engine's having access to the end user's 244 SIP authentication credentials. The Sieve engine MAY use server-wide 245 credentials (including applicable certificates) that are the same for 246 all scripts. Alternatively, it MAY, for auditing purposes, use 247 different sets of Sieve-engine credentials when operating on behalf 248 of different users. 250 See section 22 of RFC 3261 [RFC3261] for more information about SIP 251 authentication. 253 [[ADAM'S REVIEW 2; ** resolved **: My second area of concern is with 254 the handling of the "From" header field. The draft-ietf-sieve-notify 255 document clearly intends the ":from" value to indicate the value that 256 is typically rendered to the contacted party as the source of the 257 message. This intended behavior is upheld by the language in section 258 2.3 of draft-ietf-sieve-notify-mailto-10 (it places this value in the 259 SMTP "From:" header, and even suggests using the value in the "RCPT 260 FROM" command -- despite the easy availability of an SMTP "Reply-To:" 261 header). This mismatch in semantics between the protocols causes me 262 concern, as it may surprise users to have radically different 263 treatment of the value in the ":from" tag among protocols. Given the 264 text in the base sieve-notify document, I believe that the behavior 265 in sieve-notify-mailto is correct, and that the behavior in sieve- 266 notify-sip should be modified to align with it. (Indication of the 267 sending server can be made via other means, such as the SIP Call- 268 Info: header field).]] 270 [[BEN'S REVIEW, MAJOR 2a; ** resolved **: You need to consider how 271 the SIEVE implementation deals with SIP authentication, digest 272 challenges, etc. For example, if the peer SIP device responds with a 273 401 or 407 containing a digest-challenge, what credentials should be 274 used to respond to the challenge? Would you suggest the credentials 275 of a particular user? If so, are their security considerations 276 around having the SIEVE implementation know the credentials of a 277 particular user? Or should the SIEVE implementation authenticate 278 with server-wide credentials?]] 280 [[BEN'S REVIEW, MAJOR 2b; ** resolved **: Do you allow TLS mutual 281 authentication? If so, what client certificate should be 282 presented?]] 284 2.3. Notify tag ":options" 286 Handling of the ":options" tag is implementation specific. This 287 document doesn't require presence of any option and doesn't define 288 how options are processed. 290 2.4. Notify tag ":importance" 292 The ":importance" tag is intended to convey the importance of the SIP 293 MESSAGE notification, not the importance of the email message that 294 generated the notification. The value of the ":importance" tag MAY, 295 therefore, be transformed into SIP "Priority" header field (in 296 addition to or instead of including it in the body of the message). 297 If this is done, the value of the "Priority" header field MUST be 298 "urgent" if the value of the ":importance" tag is "1", "normal" if 299 the value of the ":importance" tag is "2", and "non-urgent" if the 300 value of the ":importance" tag is "3". 302 [[BEN'S REVIEW, MINOR 2; ** resolved **: Do you expect the 303 :importance tag to set the importance of the SIP MESSAGE request, or 304 to convey the importance of the email that generated the notification 305 in the first place? If the first, then you're doing it right. If 306 the second, it might be more reasonable to put something in the 307 body.]] 309 2.5. Notify tag ":message" 311 If the ":message" tag is included, it MUST be transformed into the 312 message-body of a SIP MESSAGE, which MUST have Content-Type value of 313 "text/plain" with CHARSET="UTF-8". If the ":message" tag is not 314 included, a default message will be used. The default message body 315 SHOULD contain the values of the "From" and "Subject" header fields 316 of the triggering email message (and MAY include the value of the 317 ":importance" tag, if one is specified), as shown in Section 3.2 318 below. 320 Implementations MUST comply with the SIP MESSAGE size limits, as 321 discussed in section 8 of RFC 3428 [RFC3428]. 323 [[BEN'S REVIEW, MINOR 3; ** resolved **: This section needs to 324 mention the SIP MESSAGE request size limits from RFC 3428. Is the 325 body still expected to have a content-type of text/plain if no 326 :message tag is present?]] 328 2.6. Other Definitions 330 An implementation MUST ignore any URI parameter it does not 331 understand (the URI MUST be processed as if the parameter were not 332 present). Implementations SHOULD NOT use the hname "body" parameter 333 value as the message-body of the SIP MESSAGE request. If the hname 334 "body" parameter and ":message" tag are present at the same time, the 335 "body" parameter MUST be ignored. 337 If the notification request fails, there will be a SIP error code 338 describing the failure. The policy for retrying delivery of failed 339 notifications is specified in RFC 3261 [RFC3261], according to the 340 error code. In other words, unlike the situation with some other 341 Sieve notification methods, retries for SIP MESSAGE notifications are 342 controlled by the notification protocol itself (SIP). 344 [[BEN'S REVIEW, MAJOR 3; ** resolved **: I'm not sure what you have 345 in mind here. If you are talking about request retransmission as 346 described in 3261, those are not suggestions--they are mandatory 347 parts of the SIP state machine. If you mean something like "try 348 again later because the destination party is offline" SIP doesn't 349 have much to say about that except in a few specific response 350 scenarios.]] 352 2.7. Test notify_method_capability 354 Because it is impossible to tell in advance whether the notification 355 recipient is online and able to receive a SIP MESSAGE, the 356 notify_method_capability test for "online" will always return "maybe" 357 for this notification method. 359 [[BEN'S REVIEW, MINOR 4; ** resolved **: How could you ever know 360 this, short of trying the message? The implementation would have to 361 be presence aware to ever return something other than "maybe", and 362 even then it can't be certain.]] 364 3. Examples 366 In the following examples, the sender of the email has an address of 367 juliet@example.org, the entity to be notified has a SIP address of 368 , and the notification service has a SIP 369 address . 371 3.1. Example 1 373 The following is a basic Sieve notify action with only a method: 375 notify "sip:romeo@example.com;method=MESSAGE" 377 The resulting SIP MESSAGE request might be as follows: 379 MESSAGE sip:romeo@example.com SIP/2.0 380 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 381 Max-Forwards: 70 382 From: sip:notifier@example.com;tag=32328 383 To: sip:romeo@example.com 384 Call-ID: asd88asd77a@1.2.3.4 385 CSeq: 1 MESSAGE 386 Date: Sat, 13 Nov 2010 23:29:00 GMT 387 Content-Type: text/plain 388 Content-Length: 53 390 wrote: Contact me immediately! 392 In the example above the email message was received from 393 juliet@example.com and had "Subject: Contact me immediately!" 395 3.2. Example 2 397 The following is a more advanced Sieve notify action with a method, 398 importance, subject, and message: 400 notify :importance "1" 401 :message "You got new mail!" 402 "sip:romeo@example.com;method=MESSAGE?subject=SIEVE" 404 MESSAGE sip:romeo@example.com SIP/2.0 405 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 406 Max-Forwards: 70 407 From: sip:notifier@example.com;tag=32328 408 To: sip:romeo@example.com 409 Subject: SIEVE 410 Priority: urgent 411 Call-ID: asd88asd77a@1.2.3.4 412 CSeq: 1 MESSAGE 413 Date: Fri, 08 Apr 2011 06:54:00 GMT 414 Content-Type: text/plain 415 Content-Length: 19 417 You got new mail! 419 4. Requirements Conformance Checklist 421 Section 3.8 of Sieve Notify [RFC5435] specifies a set of requirements 422 for Sieve notification methods. A checklist is provided here to show 423 conformance of the SIP MESSAGE notification method. 425 1. No new Sieve tags have been added to the "notify" action. 427 2. An implementation of the SIP MESSAGE notification method SHOULD 428 NOT modify the final notification text, except to comply with 429 SIP MESSAGE length limits. Deployments MAY make operational 430 decisions about notification text, for reasons such as privacy 431 and confidentiality. Modification of characters themselves 432 should not be necessary, since the SIP MESSAGE body is encoded 433 in UTF-8 [RFC3629]. 435 [[BEN'S REVIEW, MINOR 5; ** resolved **: There are length limits 436 for SIP MESSAGE requests that this draft should consider. They 437 are large enough to be generally non constraining for this 438 usage, but they exist.]] 440 3. An implementation MAY ignore parameters specified in the 441 ":importance", and ":options" tags. 443 4. A default message is suggested in Section 2.5. 445 5. A notification sent via the SIP MESSAGE notification method MAY 446 include the Date header field containing the date-time of the 447 moment when the SIP MESSAGE notification was generated. 449 6. The notification source is identified through the SIP "From:" 450 header field, via the Sieve Notify ":from" tag (see Section 2.2. 452 7. An implementation MUST NOT include any other extraneous 453 information not specified in parameters to the notify action. 455 8. An implementation MUST ignore any URI parameters it does not 456 understand (i.e., the URI MUST be processed as if the action or 457 parameter were not present). See Section 2.6 for more details. 459 9. The notify_method_capability test for the "online" notification- 460 capability behaves as described in Section 2.7. 462 10. The policy for retrying delivery of failed notifications is 463 specified in RFC 3261 [RFC3261], as noted in Section 2.6. 465 5. Security Considerations 467 Depending on the information included, sending a notification can be 468 comparable to forwarding mail to the notification recipient. Care 469 must be taken when forwarding mail automatically, to ensure that 470 confidential information is not sent into an insecure environment or 471 over an insecure channel. 473 User agents that support the SIP MESSAGE request MUST implement end- 474 to-end authentication, body integrity, and body confidentiality 475 mechanisms. 477 The Sieve Notify extension specifies that notification methods MUST 478 provide mechanisms for avoiding notification loops. In this case, 479 the SIP protocol itself prevents loops, and no explicit work is 480 needed within the notification mechanism. In situations where a SIP 481 MESSAGE notification can result in an email message, which could 482 generate another SIP MESSAGE notification, loop prevention through 483 rate limiting might be necessary. 485 Other security considerations given in the Sieve base specification 486 [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 487 [RFC3261] are also relevant to this document. 489 6. IANA Considerations 491 The following template provides the IANA registration of the Sieve 492 notification mechanism specified in this document. This information 493 should be added to the list of Sieve notification mechanisms 494 maintained at . 496 To: iana@iana.org 497 Subject: Registration of new Sieve notification mechanism 498 Mechanism name: sip-message 499 Mechanism URI: SIP/SIPS as specified in RFC 3261 [RFC3261] 500 Mechanism-specific options: none 501 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 502 Person and email address to contact for further information: 503 See authors of [RFC XXXX] 505 7. Acknowledgements 507 This document borrows some text from draft-ietf-sieve-notify-xmpp. 509 The authors would like to specially thank Adam Roach and Eric Burger 510 for their helpful comments. 512 8. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 518 A., Peterson, J., Sparks, R., Handley, M., and E. 519 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 520 June 2002. 522 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 523 and D. Gurle, "Session Initiation Protocol (SIP) Extension 524 for Instant Messaging", RFC 3428, December 2002. 526 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 527 10646", STD 63, RFC 3629, November 2003. 529 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 530 Language", RFC 5228, January 2008. 532 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 533 "Sieve Email Filtering: Extension for Notifications", 534 RFC 5435, January 2009. 536 Authors' Addresses 538 Alexey Melnikov 539 Isode Limited 540 5 Castle Business Village 541 36 Station Road 542 Hampton, Middlesex TW12 2BX 543 UK 545 Email: Alexey.Melnikov@isode.com 546 URI: http://www.melnikov.ca/ 548 Henning Schulzrinne 549 Columbia U. 550 Columbia University Department of Computer Science 551 New York, NY 10027 552 US 554 Phone: +1 212 939 7004 555 Email: hgs@cs.columbia.edu 556 Qian Sun 557 Huawei Technologies 558 Bantian, Longgang 559 Shenzhen, Guandong 518129 560 P.R China 562 Phone: +86 755 28780808 563 Email: sunqian@huawei.com 565 Barry Leiba 566 Huawei Technologies 568 Phone: +1 646 827 0648 569 Email: barryleiba@computer.org 570 URI: http://internetmessagingtechnology.org/ 572 Kepeng Li 573 Huawei Technologies 574 Huawei Base, Bantian, Longgang District 575 Shenzhen, Guangdong 518129 576 P. R. China 578 Phone: +86-755-28974289 579 Email: likepeng@huawei.com