idnits 2.17.1 draft-melnikov-sieve-notify-sip-message-01.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 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 396. 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 17, 2008) is 5913 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 294, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 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: August 20, 2008 Columbia U. 6 Q. Sun 7 Huawei Technologies 8 February 17, 2008 10 Sieve Notification Mechanism: SIP MESSAGE 11 draft-melnikov-sieve-notify-sip-message-01 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 August 20, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes a profile of the Sieve extension for 45 notifications, to allow notifications to be sent over the SIP 46 MESSAGE. 48 Conventions Used in this Document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . . 3 62 2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 3 64 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4 65 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 4 66 2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . 4 67 2.7. Test notify_method_capability . . . . . . . . . . . . . . . 4 69 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Requirements Conformance . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 79 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 82 Intellectual Property and Copyright Statements . . . . . . . 10 84 1. Introduction 86 1.1. Overview 88 The NOTIFY [NOTIFY] extension to the SIEVE [SIEVE] mail filtering 89 language is a framework for providing notifications by employing URIs 90 to specify the notification mechanism. This document defines how SIP 91 URIs (see RFC 3261 [SIP]) are used to generate notifications via the 92 SIP MESSAGE (see RFC 3428 [RFC3428]). 94 1.2. Terminology 96 This document inherits terminology from NOTIFY [NOTIFY], SIEVE 97 [SIEVE], and RFC 3261 [SIP]. 99 2. Definition 101 The sip message mechanism results in the sending of a SIP MESSAGE 102 request to notify a recipient about an email message. 104 2.1. Notify parameter "method" 106 The "method" parameter MUST be a URI that conforms to the SIP (or 107 SIPS) URI scheme (as specified in RFC 3261 [SIP]) and that identifies 108 a SIP (or SIPS) recipient of the notification. The URI MAY include 109 the resource identifier portion of a SIP address and URI parameters. 110 The URI parameter "method" MUST be ignored, because only the MESSAGE 111 method is allowed by this specification. The processing application 112 MUST extract a SIP address from the URI in accordance with the 113 processing rules specified in RFC 3261 [SIP]. The resulting SIP 114 address MUST be encapsulated in SIP URI syntax as Request-URI and the 115 value of the "To" header field of the SIP MESSAGE request. 117 2.2. Notify tag ":from" 119 The value of the ":from" tag MUST use the SIP "Reply-To" syntax; if 120 the :from value is specified and has valid syntax, the notification 121 MUST include the "Reply-To" SIP header field containing the value of 122 the :from notify tag. If the value has invalid syntax, this is 123 considered a Sieve script processing error. [[anchor6: Should the 124 value be ignored instead?]] 126 2.3. Notify tag ":options" 128 Handling of the ":options" tag is implementation specific. This 129 document doesn't require presence of any option and doesn't define 130 how options are processed. 132 2.4. Notify tag ":importance" 134 The value of the ":importance" tag MAY be transformed into SIP 135 "Priority" header field (in addition to or instead of including in 136 the default message); if specified, the value of the "Priority" 137 header field MUST be "urgent" if the value of the ":importance" tag 138 is "1", "normal" if the value of the ":importance" tag is "2", or 139 "non-urgent" if the value of the ":importance" tag is "3". 141 2.5. Notify tag ":message" 143 If included, the ":message" tag MUST be transformed into the message- 144 body of a SIP MESSAGE, which MUST have Content-Type value of "text/ 145 plain" with CHARSET="UTF-8". [[anchor10: Should application/ 146 sieve-notification+xml Content type from draft-mahy-sieve-notify-sip 147 be used instead?]] If not included, the default message body SHOULD 148 contain values of the "From" and "Subject" header fields of the 149 triggering email message (and MAY include the value of the 150 ":importance" tag, if one is specified), as shown in one of the 151 examples below. 153 2.6. Other Definitions 155 The value of the SIP "From" header field specified in the SIP 156 notification message MUST be the SIP address of the notification 157 service itself. 159 An implementation MUST ignore any URI parameter it does not 160 understand (i.e., the URI MUST be processed as if the parameter were 161 not present). It is RECOMMENDED not to use the hname "body" 162 parameter value as the message-body of the SIP MESSAGE request. If 163 hname "body" parameter and ":message" tag are present at the same 164 time, the "body" parameter MUST be ignored.[[anchor11: Any other SIP 165 URI parameters that should be used?]] 167 The policy of retry delivery of a notification is a matter of 168 implementation and is not specified herein. But it SHOULD follow the 169 suggestion for retry in RFC 3261 [SIP]. 171 2.7. Test notify_method_capability 173 The notify_method_capability test for "online" may return "yes" or 174 "no" only if the Sieve processor can determine with certainty whether 175 or not the recipient of the notification message is can receive the 176 notification immediately. Otherwise, the test returns "maybe" for 177 this notification method. [[anchor12: Add some specific details 178 regarding determining online status of the recipient. Also need to 179 add some text about presence leak?]] 181 3. Examples 183 In the following examples, the sender of the email has an address of 184 juliet@example.org, the entity to be notified has a SIP address of 185 , and the notification service has a SIP 186 address . 188 The following is a basic Sieve notify action with only a method: 190 notify "sip:romeo@example.com" 192 The resulting SIP MESSAGE request might be as follows: 194 MESSAGE sip:romeo@example.com SIP/2.0 195 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse 196 Max-Forwards: 70 197 From: sip:notifier@example.com;tag=32328 198 To: sip:romeo@example.com 199 Call-ID: asd88asd77a@1.2.3.4 200 CSeq: 1 MESSAGE 201 Content-Type: text/plain 202 Content-Length: 53 204 wrote: Contact me immediately! 206 In the example above the email message was received from 207 juliet@example.com and had "Subject: Contact me immediately!" 209 The following is a more advanced Sieve notify action with a method, 210 importance, subject, and message: 212 notify :importance "1" 213 :message "You got new mail!" 214 "sip:romeo@example.com?subject=SIEVE" 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 Subject: SIEVE 222 Priority: urgent 223 Call-ID: asd88asd77a@1.2.3.4 224 CSeq: 1 MESSAGE 225 Content-Type: text/plain 226 Content-Length: 19 228 You got new mail! 230 4. Requirements Conformance 232 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve 233 notification methods. The conformance of the SIP MESSAGE 234 notification mechanism is provided here.[[anchor15: This section 235 needs more work.]] 236 1. An implementation of the SIP MESSAGE notification method SHOULD 237 NOT modify the final notification text (e.g., to limit the 238 length); however, a given deployment MAY do so. Modification of 239 characters themselves should not be necessary, since SIP MESSAGE 240 body is encoded in UTF-8 [RFC3629]. 241 2. An implementation MAY ignore parameters specified in the 242 ":importance", and ":options" tags. 243 3. If not included, the default message body SHOULD contain values 244 of the "From" and "Subject" header fields of the triggering 245 email message (and MAY include the value of the ":importance" 246 tag, if one is specified), as shown in one of the examples 247 below. 248 4. A notification sent via the SIP message notification method MAY 249 include a timestamp in the textual message. [[anchor16: Should 250 the SIP Date header field be used for timestamp instead?]] 251 5. The value of the SIP "From" header field MUST be the SIP address 252 of the notification service associated with the SIEVE engine. 253 6. The value of the Sieve ":from" tag MUST be transformed into the 254 value of an SIP "Reply-To" header field. 255 7. The value of the SIP "To" header field MUST be the SIP address 256 specified in the SIP URI contained in the "method" parameter. 258 8. An implementation MUST ignore any URI parameters it does not 259 understand (i.e., the URI MUST be processed as if the action or 260 parameter were not present). See Section 2.6 for more details. 261 9. An implementation MUST NOT include any other extraneous 262 information not specified in parameters to the notify action. 263 10. The notify_method_capability test for the "online" notification- 264 capability behaves as described in Section 2.7. 266 5. Security Considerations 268 [[anchor17: TBD]] 270 Depending on the information included, sending a notification can be 271 comparable to forwarding mail to the notification recipient. Care 272 must be taken when forwarding mail automatically, to ensure that 273 confidential information is not sent into an insecure environment or 274 over an insecure channel. 276 UAs that support the MESSAGE request MUST implement end-to-end 277 authentication, body integrity, and body confidentiality mechanisms. 279 Other security considerations given in [NOTIFY], [SIEVE] and [SIP] 280 are also relevant to this document. 282 6. IANA Considerations 284 The following template provides the IANA registration of the Sieve 285 notification mechanism specified in this document: 287 To: iana@iana.org 288 Subject: Registration of new Sieve notification mechanism 289 Mechanism name: sip-message 290 Mechanism URI: RFC 3261 [SIP] 291 Mechanism-specific options: none 292 Standards Track/IESG-approved experimental RFC number: [RFC XXXX] 293 Person and email address to contact for further information: 294 See authors of [RFC XXXX] 296 This information should be added to the list of Sieve notification 297 mechanisms maintained at 298 . 300 7. Acknowledgements 302 This document borrows some text from draft-ietf-sieve-notify-xmpp. 304 8. Normative References 306 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 307 Martin, "Sieve Extension: Notifications", 308 draft-ietf-sieve-notify-12 (work in progress), 309 December 2007. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", RFC 2119, BCP 14, March 1997. 314 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 315 and D. Gurle, "Session Initiation Protocol (SIP) Extension 316 for Instant Messaging", RFC 3428, December 2002. 318 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 319 10646", STD 63, RFC 3629, November 2003. 321 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 322 Filtering Language", RFC 5228, January 2008. 324 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 325 A., Peterson, J., Sparks, R., Handley, M., and E. 326 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 327 June 2002. 329 Authors' Addresses 331 Alexey Melnikov 332 Isode Limited 333 5 Castle Business Village 334 36 Station Road 335 Hampton, Middlesex TW12 2BX 336 UK 338 Email: Alexey.Melnikov@isode.com 339 URI: http://www.melnikov.ca/ 341 Henning Schulzrinne 342 Columbia U. 343 Columbia University Department of Computer Science 344 New York, NY 10027 345 US 347 Phone: +1 212 939 7004 348 Email: hgs@cs.columbia.edu 349 Qian Sun 350 Huawei Technologies 351 Bantian Longgang 352 Shenzhen, Guandong 518129 353 P.R China 355 Phone: +86 755 28780808 356 Email: sunqian@huawei.com 358 Full Copyright Statement 360 Copyright (C) The IETF Trust (2008). 362 This document is subject to the rights, licenses and restrictions 363 contained in BCP 78, and except as set forth therein, the authors 364 retain all their rights. 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 369 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 370 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 371 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 Intellectual Property 376 The IETF takes no position regarding the validity or scope of any 377 Intellectual Property Rights or other rights that might be claimed to 378 pertain to the implementation or use of the technology described in 379 this document or the extent to which any license under such rights 380 might or might not be available; nor does it represent that it has 381 made any independent effort to identify any such rights. Information 382 on the procedures with respect to rights in RFC documents can be 383 found in BCP 78 and BCP 79. 385 Copies of IPR disclosures made to the IETF Secretariat and any 386 assurances of licenses to be made available, or the result of an 387 attempt made to obtain a general license or permission for the use of 388 such proprietary rights by implementers or users of this 389 specification can be obtained from the IETF on-line IPR repository at 390 http://www.ietf.org/ipr. 392 The IETF invites any interested party to bring to its attention any 393 copyrights, patents or patent applications, or other proprietary 394 rights that may cover technology that may be required to implement 395 this standard. Please address the information to the IETF at 396 ietf-ipr@ietf.org. 398 Acknowledgment 400 Funding for the RFC Editor function is provided by the IETF 401 Administrative Support Activity (IASA).