idnits 2.17.1 draft-ietf-sieve-notify-xmpp-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 1, 2007) is 6052 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) == Outdated reference: A later version (-12) exists of draft-ietf-sieve-notify-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'OOB' -- Possible downref: Non-RFC (?) normative reference: ref. 'QUERIES' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHIM' == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group P. Saint-Andre 3 Internet-Draft XMPP Standards Foundation 4 Intended status: Standards Track A. Melnikov 5 Expires: April 3, 2008 Isode Limited 6 October 1, 2007 8 Sieve Notification Mechanism: xmpp 9 draft-ietf-sieve-notify-xmpp-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 3, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a profile of the Sieve extension for 43 notifications, to allow notifications to be sent over the Extensible 44 Messaging and Presence Protocol (XMPP), also known as Jabber. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . 3 53 2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . 4 54 2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . 4 55 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . 4 56 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . 4 57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Requirements Conformance . . . . . . . . . . . . . . . . . . . 5 59 5. Internationalization Considerations . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Intellectual Property and Copyright Statements . . . . . . . . . . 10 68 1. Introduction 70 1.1. Overview 72 The [NOTIFY] extension to the [SIEVE] mail filtering language is a 73 framework for providing notifications by employing URIs to specify 74 the notification mechanism. This document defines how xmpp URIs (see 75 [XMPP-URI]) are used to generate notifications via the Extensible 76 Messaging and Presence Protocol (see [XMPP]), which is widely 77 implemented in Jabber instant messaging technologies. 79 1.2. Terminology 81 This document inherits terminology from [NOTIFY], [SIEVE], and 82 [XMPP]. 84 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 85 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 86 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 87 interpreted as described in [TERMS]. 89 2. Definition 91 The xmpp mechanism results in the sending of an XMPP message to 92 notify a recipient about an email message. The general XMPP syntax 93 is as follows: 95 o The notification MUST be an XMPP stanza. 96 o The value of the XMPP 'type' attribute MUST be 'headline' or 97 'normal'. 98 o The value of the XMPP 'from' attribute MUST be the XMPP address of 99 the notification service. 100 o The XMPP stanza MAY include a child element 101 whose value is some configurable text indicating that the message 102 is a Sieve notification. 103 o The notification SHOULD include a URL for the recipient to use as 104 a hint in locating the message, encapsulated as the XML character 105 data of a child element of an element qualified by the 106 'jabber:x:oob' namespace as specified in [OOB]. 108 The recommended mapping of the Sieve notify action into XMPP syntax 109 is described in the following sections. 111 2.1. Notify parameter "method" 113 The "method" parameter MUST be a URI that conforms to the xmpp URI 114 scheme (as specified in [XMPP-URI]) and that identifies an XMPP 115 account associated with the email inbox. The URI MAY include the 116 resource identifier portion of an XMPP address but SHOULD NOT include 117 an authority component, query component, or fragment identifier 118 component. The processing application MUST extract an XMPP address 119 from the URI in accordance with the processing rules specified in 120 [XMPP-URI]. The resulting XMPP address MUST be encapsulated in XMPP 121 syntax as the value of the XMPP 'to' attribute. 123 2.2. Notify tag ":from" 125 The ":from" tag has no special meaning for this notification 126 mechanism, and this specification puts no restriction on its use. As 127 noted, the value of the XMPP 'from' attribute specified in the XMPP 128 notification message MUST be the XMPP address of the notification 129 service itself. The value of the ":from" tag MAY be transformed into 130 XMPP syntax; if so, it SHOULD be encapsulated as the value of an XMPP 131 [SHIM] header named "Reply-To". 133 2.3. Notify tag ":options" 135 The ":options" tag has no special meaning for this notification 136 mechanism. Any handling of this tag is the responsibility of an 137 implementation. 139 2.4. Notify tag ":importance" 141 The ":importance" tag has no special meaning for this notification 142 mechanism, and this specification puts no restriction on its use. 143 The value of the ":importance" tag MAY be transformed into XMPP 144 syntax (in addition to or instead of including in the default 145 message); if so, it MUST be encapsulated as the value of an XMPP 146 [SHIM] header named "Urgency", and the XML character of that header 147 MUST be "high" if the value of the ":importance" tag is "1", "medium" 148 if the value of the ":importance" tag is "2", or "low" if the value 149 of the ":importance" tag is "3". 151 2.5. Notify tag ":message" 153 If included, the ":message" tag MUST be transformed into the XML 154 character data of an XMPP element. If not included, the rule 155 specified in [NOTIFY] SHOULD be followed, as shown in the examples 156 below. 158 3. Examples 160 In the following examples, the sender of the email has an address of 161 , the entity to be notified has an XMPP 162 address of romeo@example.com (resulting in an XMPP URI of 163 ), and the notification service has an XMPP 164 address of notify.example.com (resulting in an XMPP URI of ). 167 The following is a basic Sieve notify action with only a method: 169 notify "xmpp:romeo@example.com" 171 The resulting XMPP stanza might be as follows: 173 176 A Sieve instant notification! 177 <juliet@example.org> Wherefore art thou? 178 180 The following is a more advanced Sieve notify action with a method, 181 importance, subject, and message, as well as a URL pointing to the 182 message: 184 notify :importance "1" 185 :message "Contact Juliet immediately!" 186 "xmpp:romeo@example.com?message;subject=SIEVE" 188 The resulting XMPP stanza might be as follows: 190 193 SIEVE 194 Contact Juliet immediately! 195 196
high
197 198 199 200 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20 201 202 203 205 4. Requirements Conformance 207 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve 208 notification methods. The conformance of the xmpp notification 209 mechanism is provided here. 211 1. An implementation of the xmpp notification method SHOULD NOT 212 modify the final notification text (e.g., to limit the length); 213 however, a given deployment MAY do so (e.g., if recipients pay 214 per character or byte for XMPP messages). Modification of 215 characters themselves should not be necessary, since XMPP 216 character data is encoded in [UTF-8]. 217 2. An implementation MAY ignore parameters specified in the ":from", 218 ":importance", and ":options" tags. 219 3. There is no recommended default message for an implementation to 220 include if the ":message" argument is not specified. 221 4. A notification sent via the xmpp notification method MAY include 222 a timestamp in the textual message. 223 5. The value of the XMPP 'from' attribute MUST be the XMPP address 224 of the xmpp notification service. The value of the Sieve ":from" 225 tag MAY be transformed into the value of an XMPP [SHIM] header 226 named "Reply-To". 227 6. An implementation MUST NOT include any other extraneous 228 information not specified in parameters to the notify action. 229 7. In accordance with [XMPP-URI], an implementation MUST ignore any 230 URI action or parameter it does not understand (i.e., the URI 231 MUST be processed as if the action or parameter were not 232 present). It is RECOMMENDED to support the XMPP "message" query 233 type (see [QUERIES]) and the associated "body" and "subject" 234 parameters, which parameters SHOULD be mapped to the XMPP 235 and child elements of the XMPP stanza type, 236 respectively. However, if included then the Sieve notify 237 ":message" parameter MUST be mapped to the XMPP element, 238 overriding the "body" parameter (if any) included in the XMPP 239 URI. 240 8. In response to a notify_method_capability test for the "online" 241 notification-capability, an implementation SHOULD return a value 242 of "yes" if it has knowledge of an active presence session for 243 the specified notification-uri and a value of "no" if it does not 244 have such knowledge. 245 9. An implementation SHOULD NOT attempt to retry delivery of a 246 notification if it receives an XMPP error of type "auth" or 247 "cancel", MAY attempt to retry delivery if it receives an XMPP 248 error of type "wait", and MAY attempt to retry delivery if it 249 receives an XMPP error of "modify" but only if it makes 250 appropriate modifications to the notification (see [XMPP]); in 251 any case the number of retries SHOULD be limited to a 252 configurable number no less than 3 and no more than 10. An 253 implementation MAY throttle notifications if the number of 254 notifications within a given time period becomes excessive 255 according to local service policy. Duplicate suppression (if 256 any) is a matter of implementation and is not specified herein. 258 5. Internationalization Considerations 260 Although an XMPP address may contain nearly any [UNICODE] character, 261 the value of the "method" parameter MUST be a Uniform Resource 262 Identifier (see [URI]) rather than an Internationalized Resource 263 Identifier (see [IRI]). The rules specified in [XMPP-URI] MUST be 264 followed when generating XMPP URIs. 266 In accordance with Section 13 of RFC 3920, all data sent over XMPP 267 MUST be encoded in [UTF-8]. 269 6. Security Considerations 271 Depending on the information included, sending a notification can be 272 comparable to forwarding mail to the notification recipient. Care 273 must be taken when forwarding mail automatically, to ensure that 274 confidential information is not sent into an insecure environment. 275 In particular, implementations MUST conform to the security 276 considerations given in [NOTIFY], [SIEVE], and [XMPP]. 278 7. IANA Considerations 280 The following template provides the IANA registration of the Sieve 281 notification mechanism specified in this document: 283 To: iana@iana.org 284 Subject: Registration of new Sieve notification mechanism 285 Mechanism name: xmpp 286 Mechanism URI: RFC4622 287 Mechanism-specific tags: none 288 Standards Track/IESG-approved experimental RFC number: this RFC 289 Person and email address to contact for further information: 290 Peter Saint-Andre 292 This information should be added to the list of Sieve notification 293 mechanisms maintained at 294 . 296 8. References 298 8.1. Normative References 300 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 301 "Sieve Extension: Notifications", 302 draft-ietf-sieve-notify-08 (work in progress), July 2007. 304 [OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066, 305 August 2006. 307 [QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF 308 XEP 0147, September 2006. 310 [SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and 311 Internet Metadata", XSF XEP 0131, August 2005. 313 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 314 Language", draft-ietf-sieve-3028bis-12 (work in progress), 315 February 2007. 317 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [XMPP-URI] 321 Saint-Andre, P., "Internationalized Resource Identifiers 322 (IRIs) and Uniform Resource Identifiers (URIs) for the 323 Extensible Messaging and Presence Protocol (XMPP)", 324 draft-saintandre-rfc4622bis-01 (work in progress), 325 June 2007. 327 8.2. Informative References 329 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 330 Identifiers (IRIs)", RFC 3987, January 2005. 332 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 333 3.2.0", 2000. 335 The Unicode Standard, Version 3.2.0 is defined by The 336 Unicode Standard, Version 3.0 (Reading, MA, Addison- 337 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 338 Unicode Standard Annex #27: Unicode 3.1 339 (http://www.unicode.org/reports/tr27/) and by the Unicode 340 Standard Annex #28: Unicode 3.2 341 (http://www.unicode.org/reports/tr28/). 343 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 344 Resource Identifier (URI): Generic Syntax", STD 66, 345 RFC 3986, January 2005. 347 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 348 10646", STD 63, RFC 3629, November 2003. 350 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 351 Protocol (XMPP): Core", RFC 3920, October 2004. 353 Authors' Addresses 355 Peter Saint-Andre 356 XMPP Standards Foundation 358 Email: stpeter@jabber.org 359 URI: https://stpeter.im/ 361 Alexey Melnikov 362 Isode Limited 364 Email: Alexey.Melnikov@isode.com 366 Full Copyright Statement 368 Copyright (C) The IETF Trust (2007). 370 This document is subject to the rights, licenses and restrictions 371 contained in BCP 78, and except as set forth therein, the authors 372 retain all their rights. 374 This document and the information contained herein are provided on an 375 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 376 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 377 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 378 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 379 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 380 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 382 Intellectual Property 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; nor does it represent that it has 389 made any independent effort to identify any such rights. Information 390 on the procedures with respect to rights in RFC documents can be 391 found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use of 396 such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository at 398 http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at 404 ietf-ipr@ietf.org. 406 Acknowledgment 408 Funding for the RFC Editor function is provided by the IETF 409 Administrative Support Activity (IASA).