idnits 2.17.1 draft-ietf-sieve-notify-sip-message-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. 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 Copyright Line does not match the current year -- The document date (December 11, 2008) is 5615 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 292, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). 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: June 14, 2009 Columbia U. 6 Q. Sun 7 Huawei Technologies 8 December 11, 2008 10 Sieve Notification Mechanism: SIP MESSAGE 11 draft-ietf-sieve-notify-sip-message-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 14, 2009. 38 Abstract 40 This document describes a profile of the Sieve extension for 41 notifications, to allow notifications to be sent over the SIP 42 MESSAGE. 44 Table of Contents 46 1. Conventions Used in this Document . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Notify parameter "method" . . . . . . . . . . . . . . . . . 3 54 3.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3 55 3.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 4 56 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4 57 3.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 4 58 3.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . 4 59 3.7. Test notify_method_capability . . . . . . . . . . . . . . . 5 61 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Requirements Conformance . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 74 Intellectual Property and Copyright Statements . . . . . . . 10 76 1. Conventions Used in this Document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 2. Introduction 84 2.1. Overview 86 The NOTIFY [NOTIFY] extension to the SIEVE [SIEVE] mail filtering 87 language is a framework for providing notifications by employing URIs 88 to specify the notification mechanism. This document defines how SIP 89 URIs (see RFC 3261 [SIP]) are used to generate notifications via the 90 SIP MESSAGE (see RFC 3428 [RFC3428]). 92 2.2. Terminology 94 This document inherits terminology from NOTIFY [NOTIFY], SIEVE 95 [SIEVE], and RFC 3261 [SIP]. 97 3. Definition 99 The sip message mechanism results in the sending of a SIP MESSAGE 100 request to notify a recipient about an email message. 102 3.1. Notify parameter "method" 104 The "method" parameter MUST be a URI that conforms to the SIP (or 105 SIPS) URI scheme (as specified in RFC 3261 [SIP]) and that identifies 106 a SIP (or SIPS) recipient of the notification. The URI MAY include 107 the resource identifier portion of a SIP address and URI parameters. 108 The URI parameter "method" MUST be ignored, because only the MESSAGE 109 method is allowed by this specification. The processing application 110 MUST extract a SIP address from the URI in accordance with the 111 processing rules specified in RFC 3261 [SIP]. The resulting SIP 112 address MUST be encapsulated in SIP URI syntax as Request-URI and the 113 value of the "To" header field of the SIP MESSAGE request. 115 3.2. Notify tag ":from" 117 The value of the ":from" tag MUST use the SIP "Reply-To" syntax; if 118 the :from value is specified and has valid syntax, the notification 119 SHOULD include the "Reply-To" SIP header field containing the value 120 of the :from notify tag. If the value has invalid syntax, this is 121 considered a Sieve script processing error. [[anchor7: Should the 122 value be ignored instead?]] 124 3.3. Notify tag ":options" 126 Handling of the ":options" tag is implementation specific. This 127 document doesn't require presence of any option and doesn't define 128 how options are processed. 130 3.4. Notify tag ":importance" 132 The value of the ":importance" tag MAY be transformed into SIP 133 "Priority" header field (in addition to or instead of including in 134 the default message); if specified, the value of the "Priority" 135 header field MUST be "urgent" if the value of the ":importance" tag 136 is "1", "normal" if the value of the ":importance" tag is "2", or 137 "non-urgent" if the value of the ":importance" tag is "3". 139 3.5. Notify tag ":message" 141 If included, the ":message" tag MUST be transformed into the message- 142 body of a SIP MESSAGE, which MUST have Content-Type value of "text/ 143 plain" with CHARSET="UTF-8". [[anchor11: Should application/ 144 sieve-notification+xml Content type from draft-mahy-sieve-notify-sip 145 be used instead?]] If not included, the default message body SHOULD 146 contain values of the "From" and "Subject" header fields of the 147 triggering email message (and MAY include the value of the 148 ":importance" tag, if one is specified), as shown in one of the 149 examples below. 151 3.6. Other Definitions 153 The value of the SIP "From" header field specified in the SIP 154 notification message MUST be the SIP address of the notification 155 service itself. 157 An implementation MUST ignore any URI parameter it does not 158 understand (i.e., the URI MUST be processed as if the parameter were 159 not present). It is RECOMMENDED not to use the hname "body" 160 parameter value as the message-body of the SIP MESSAGE request. If 161 hname "body" parameter and ":message" tag are present at the same 162 time, the "body" parameter MUST be ignored.[[anchor12: Any other SIP 163 URI parameters that should be used?]] 165 The policy of retry delivery of a notification is a matter of 166 implementation and is not specified herein. But it SHOULD follow the 167 suggestion for retry in RFC 3261 [SIP]. 169 3.7. Test notify_method_capability 171 The notify_method_capability test for "online" may return "yes" or 172 "no" only if the Sieve processor can determine with certainty whether 173 or not the recipient of the notification message is can receive the 174 notification immediately. Otherwise, the test returns "maybe" for 175 this notification method. [[anchor13: Add some specific details 176 regarding determining online status of the recipient. Also need to 177 add some text about presence leak?]] 179 4. Examples 181 In the following examples, the sender of the email has an address of 182 juliet@example.org, the entity to be notified has a SIP address of 183 , and the notification service has a SIP 184 address . 186 The following is a basic Sieve notify action with only a method: 188 notify "sip:romeo@example.com" 190 The resulting SIP MESSAGE request might be as follows: 192 MESSAGE sip:romeo@example.com SIP/2.0 193 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 194 Max-Forwards: 70 195 From: sip:notifier@example.com;tag=32328 196 To: sip:romeo@example.com 197 Call-ID: asd88asd77a@1.2.3.4 198 CSeq: 1 MESSAGE 199 Content-Type: text/plain 200 Content-Length: 53 202 wrote: Contact me immediately! 204 In the example above the email message was received from 205 juliet@example.com and had "Subject: Contact me immediately!" 207 The following is a more advanced Sieve notify action with a method, 208 importance, subject, and message: 210 notify :importance "1" 211 :message "You got new mail!" 212 "sip:romeo@example.com?subject=SIEVE" 214 MESSAGE sip:romeo@example.com SIP/2.0 215 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 216 Max-Forwards: 70 217 From: sip:notifier@example.com;tag=32328 218 To: sip:romeo@example.com 219 Subject: SIEVE 220 Priority: urgent 221 Call-ID: asd88asd77a@1.2.3.4 222 CSeq: 1 MESSAGE 223 Content-Type: text/plain 224 Content-Length: 19 226 You got new mail! 228 5. Requirements Conformance 230 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve 231 notification methods. The conformance of the SIP MESSAGE 232 notification mechanism is provided here.[[anchor16: This section 233 needs more work.]] 234 1. An implementation of the SIP MESSAGE notification method SHOULD 235 NOT modify the final notification text (e.g., to limit the 236 length); however, a given deployment MAY do so. Modification of 237 characters themselves should not be necessary, since SIP MESSAGE 238 body is encoded in UTF-8 [RFC3629]. 239 2. An implementation MAY ignore parameters specified in the 240 ":importance", and ":options" tags. 241 3. If not included, the default message body SHOULD contain values 242 of the "From" and "Subject" header fields of the triggering 243 email message (and MAY include the value of the ":importance" 244 tag, if one is specified), as shown in one of the examples 245 below. 246 4. A notification sent via the SIP message notification method MAY 247 include a timestamp in the textual message. [[anchor17: Should 248 the SIP Date header field be used for timestamp instead?]] 249 5. The value of the SIP "From" header field MUST be the SIP address 250 of the notification service associated with the SIEVE engine. 251 6. The value of the Sieve ":from" tag SHOULD be transformed into 252 the value of an SIP "Reply-To" header field. 253 7. The value of the SIP "To" header field MUST be the SIP address 254 specified in the SIP URI contained in the "method" parameter. 256 8. An implementation MUST ignore any URI parameters it does not 257 understand (i.e., the URI MUST be processed as if the action or 258 parameter were not present). See Section 3.6 for more details. 259 9. An implementation MUST NOT include any other extraneous 260 information not specified in parameters to the notify action. 261 10. The notify_method_capability test for the "online" notification- 262 capability behaves as described in Section 3.7. 264 6. Security Considerations 266 [[anchor18: TBD]] 268 Depending on the information included, sending a notification can be 269 comparable to forwarding mail to the notification recipient. Care 270 must be taken when forwarding mail automatically, to ensure that 271 confidential information is not sent into an insecure environment or 272 over an insecure channel. 274 UAs that support the MESSAGE request MUST implement end-to-end 275 authentication, body integrity, and body confidentiality mechanisms. 277 Other security considerations given in [NOTIFY], [SIEVE] and [SIP] 278 are also relevant to this document. 280 7. IANA Considerations 282 The following template provides the IANA registration of the Sieve 283 notification mechanism specified in this document: 285 To: iana@iana.org 286 Subject: Registration of new Sieve notification mechanism 287 Mechanism name: sip-message 288 Mechanism URI: SIP/SIPS as specified in RFC 3261 [SIP] 289 Mechanism-specific options: none 290 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 291 Person and email address to contact for further information: 292 See authors of [RFC XXXX] 294 This information should be added to the list of Sieve notification 295 mechanisms maintained at 296 . 298 8. Acknowledgements 300 This document borrows some text from draft-ietf-sieve-notify-xmpp. 302 9. Normative References 304 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 305 Martin, "Sieve Extension: Notifications", 306 draft-ietf-sieve-notify-12 (work in progress), 307 December 2007. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", RFC 2119, BCP 14, March 1997. 312 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 313 and D. Gurle, "Session Initiation Protocol (SIP) Extension 314 for Instant Messaging", RFC 3428, December 2002. 316 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 317 10646", STD 63, RFC 3629, November 2003. 319 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 320 Filtering Language", RFC 5228, January 2008. 322 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 323 A., Peterson, J., Sparks, R., Handley, M., and E. 324 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 325 June 2002. 327 Authors' Addresses 329 Alexey Melnikov 330 Isode Limited 331 5 Castle Business Village 332 36 Station Road 333 Hampton, Middlesex TW12 2BX 334 UK 336 Email: Alexey.Melnikov@isode.com 337 URI: http://www.melnikov.ca/ 339 Henning Schulzrinne 340 Columbia U. 341 Columbia University Department of Computer Science 342 New York, NY 10027 343 US 345 Phone: +1 212 939 7004 346 Email: hgs@cs.columbia.edu 347 Qian Sun 348 Huawei Technologies 349 Bantian Longgang 350 Shenzhen, Guandong 518129 351 P.R China 353 Phone: +86 755 28780808 354 Email: sunqian@huawei.com 356 Full Copyright Statement 358 Copyright (C) The IETF Trust (2008). 360 This document is subject to the rights, licenses and restrictions 361 contained in BCP 78, and except as set forth therein, the authors 362 retain all their rights. 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 368 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Intellectual Property 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; nor does it represent that it has 379 made any independent effort to identify any such rights. Information 380 on the procedures with respect to rights in RFC documents can be 381 found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use of 386 such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository at 388 http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention any 391 copyrights, patents or patent applications, or other proprietary 392 rights that may cover technology that may be required to implement 393 this standard. Please address the information to the IETF at 394 ietf-ipr@ietf.org.