idnits 2.17.1 draft-ietf-sieve-notify-xmpp-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 23, 2006) is 6517 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) == Unused Reference: 'RFC1327' is defined on line 236, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-sieve-notify-03 == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-06 ** Obsolete normative reference: RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 1327 (Obsoleted by RFC 2156) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 Jabber Software Foundation 4 Expires: December 25, 2006 A. Melnikov 5 Isode Limited 6 June 23, 2006 8 Sieve Notification Mechanism: xmpp 9 draft-ietf-sieve-notify-xmpp-01 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 December 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 tag ":method" . . . . . . . . . . . . . . . . . . . 3 53 2.2 Notify tag ":from" . . . . . . . . . . . . . . . . . . . . 4 54 2.3 Notify tag ":options" . . . . . . . . . . . . . . . . . . 4 55 2.4 Notify tag ":priority" . . . . . . . . . . . . . . . . . . 4 56 2.5 Notify tag ":message" . . . . . . . . . . . . . . . . . . 4 57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Internationalization Considerations . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 62 6.2 Informative References . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 64 Intellectual Property and Copyright Statements . . . . . . . . 8 66 1. Introduction 68 1.1 Overview 70 The [NOTIFY] extension to the [SIEVE] mail filtering language is a 71 framework for providing notifications by employing URIs to specify 72 the notification mechanism. This document defines how xmpp URIs (see 73 [XMPP-URI]) are used to generate notifications via the Extensible 74 Messaging and Presence Protocol (see [XMPP]), also known as Jabber. 76 1.2 Terminology 78 This document inherits terminology from [NOTIFY], [SIEVE], and 79 [XMPP]. 81 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 82 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 83 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 84 interpreted as described in RFC 2119 [TERMS]. 86 2. Definition 88 The xmpp mechanism results in the sending of an XMPP message to 89 notify a recipient about an email message. The notification MUST be 90 an XMPP stanza. The value of the XMPP 'type' attribute 91 MUST be 'headline' or 'normal'. The value of the XMPP 'from' 92 attribute MUST be the XMPP address of the notification service. The 93 XMPP stanza MAY include a child element whose 94 value is some configurable text indicating that the message is a 95 Sieve notification. 97 The format of the notify action is described in the following 98 sections. 100 2.1 Notify tag ":method" 102 The ":method" tag MUST be a URI that conforms to the xmpp URI scheme 103 (as specified in [XMPP-URI]) and that identifies an XMPP account 104 associated with the email inbox. The URI MAY include the resource 105 identifier portion of an XMPP address but SHOULD NOT include an 106 authority component, query component, or fragment identifier 107 component. The processing application MUST extract an XMPP address 108 from the URI in accordance with the processing rules specified in 109 [XMPP-URI]. The resulting XMPP address MUST be encapsulated in XMPP 110 syntax as the value of the XMPP 'to' attribute. 112 2.2 Notify tag ":from" 114 The ":from" tag has no special meaning for this notification 115 mechanism, and this specification puts no restriction on its use. As 116 noted, the value of the XMPP 'from' attribute specified in the XMPP 117 notification message MUST be the XMPP address of the notification 118 service itself. The value of the ":from" tag MAY be transformed into 119 XMPP syntax; if so, it SHOULD be encapsulated as the value of an 120 [XMPP-SHIM] header named "Reply-To". 122 2.3 Notify tag ":options" 124 The ":options" tag has no special meaning for this notification 125 mechanism. Any handling of this tag is the responsibility of an 126 implementation. 128 2.4 Notify tag ":priority" 130 The ":priority" tag has no special meaning for this notification 131 mechanism, and this specification puts no restriction on its use. 132 The value of the ":priority" tag MAY be transformed into XMPP syntax; 133 if so, it SHOULD be encapsulated as the value of an [XMPP-SHIM] 134 header named "Urgency", and the XML character of that header SHOULD 135 be "high" if the value of the ":priority" tag is "1", "medium" if the 136 value of the ":priority" tag is "2", or "low" if the value of the 137 ":priority" tag is "3". 139 2.5 Notify tag ":message" 141 If included, the ":message" tag SHOULD be transformed into the XML 142 character data of an XMPP element. If not included, the rule 143 specified in [NOTIFY] SHOULD be followed, as shown in the examples 144 below. 146 3. Examples 148 In the following examples, the sender of the email has an address of 149 , the entity to be notified has an XMPP 150 address of , and the notification service has 151 an XMPP address . 153 The following is a basic Sieve notify action with only a method: 155 notify :method "xmpp:romeo@example.com" 157 The resulting XMPP stanza might be as follows: 159 162 A Sieve instant notification! 163 <juliet@example.org> Wherefore art thou? 164 166 The following is a more advanced Sieve notify action with a method, 167 priority, and message: 169 notify :method "xmpp:romeo@example.com" 170 :priority "high" 171 :message "Contact Juliet immediately!" 173 The resulting XMPP stanza might be as follows: 175 178 A Sieve instant notification! 179 Contact Juliet immediately! 180 181
high
182 183 185 4. Internationalization Considerations 187 Although an XMPP address may contain nearly any [UNICODE] character, 188 the value of the ":method" tag MUST be a Uniform Resource Identifier 189 (see [URI]) rather than an Internationalized Resource Identifier (see 190 [IRI]). The rules specified in [XMPP-URI] MUST be followed when 191 generating XMPP URIs. 193 In accordance with Section 13 of RFC 3920, all data sent over XMPP 194 MUST be encoded in [UTF-8]. 196 5. Security Considerations 198 Depending on the information included, sending a notification can be 199 comparable to forwarding mail to the notification recipient. Care 200 must be taken when forwarding mail automatically, to ensure that 201 confidential information is not sent into an insecure environment. 202 In particular, implementations MUST conform to the security 203 considerations given in [NOTIFY], [SIEVE], and [XMPP]. 205 6. References 206 6.1 Normative References 208 [NOTIFY] Melnikov, A., "Sieve Extension: Notifications", 209 draft-ietf-sieve-notify-03 (work in progress), June 2006. 211 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 212 Language", draft-ietf-sieve-3028bis-06 (work in progress), 213 March 2006. 215 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 219 10646", STD 63, RFC 3629, November 2003. 221 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 222 Protocol (XMPP): Core", RFC 3920, October 2004. 224 [XMPP-URI] 225 Saint-Andre, P., "Internationalized Resource Identifiers 226 (IRIs) and Uniform Resource Identifiers (URIs) for the 227 Extensible Messaging and Presence Protocol (XMPP)", 228 draft-saintandre-xmpp-iri-04 (work in progress), 229 March 2006. 231 6.2 Informative References 233 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 234 Identifiers (IRIs)", RFC 3987, January 2005. 236 [RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 237 10021 and RFC 822", RFC 1327, May 1992. 239 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 240 3.2.0", 2000. 242 The Unicode Standard, Version 3.2.0 is defined by The 243 Unicode Standard, Version 3.0 (Reading, MA, Addison- 244 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 245 Unicode Standard Annex #27: Unicode 3.1 246 (http://www.unicode.org/reports/tr27/) and by the Unicode 247 Standard Annex #28: Unicode 3.2 248 (http://www.unicode.org/reports/tr28/). 250 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 251 Resource Identifier (URI): Generic Syntax", STD 66, 252 RFC 3986, January 2005. 254 [XMPP-SHIM] 255 Saint-Andre, P. and J. Hildebrand, "Stanza Headers and 256 Internet Metadata (SHIM)", JSF JEP 0131, August 2005. 258 Authors' Addresses 260 Peter Saint-Andre 261 Jabber Software Foundation 263 Email: stpeter@jabber.org 265 Alexey Melnikov 266 Isode Limited 268 Email: Alexey.Melnikov@isode.com 270 Intellectual Property Statement 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at 292 ietf-ipr@ietf.org. 294 Disclaimer of Validity 296 This document and the information contained herein are provided on an 297 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 298 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 299 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 300 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 301 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 302 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 304 Copyright Statement 306 Copyright (C) The Internet Society (2006). This document is subject 307 to the rights, licenses and restrictions contained in BCP 78, and 308 except as set forth therein, the authors retain all their rights. 310 Acknowledgment 312 Funding for the RFC Editor function is currently provided by the 313 Internet Society.