idnits 2.17.1 draft-ietf-sieve-notify-xmpp-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 242. ** 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 (January 17, 2006) is 6667 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 183, but no explicit reference was found in the text == Unused Reference: 'UTF-8' is defined on line 201, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-sieve-notify-01 == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-05 ** Obsolete normative reference: RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) == Outdated reference: A later version (-04) exists of draft-saintandre-xmpp-iri-03 -- Obsolete informational reference (is this intentional?): RFC 1327 (Obsoleted by RFC 2156) Summary: 5 errors (**), 0 flaws (~~), 8 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: July 21, 2006 A. Melnikov 5 Isode Limited 6 January 17, 2006 8 Sieve Notification Mechanism: xmpp 9 draft-ietf-sieve-notify-xmpp-00 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 July 21, 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 ":method" tag . . . . . . . . . . . . . . . . . . . 3 53 2.2 Notify ":priority" tag . . . . . . . . . . . . . . . . . . 4 54 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Internationalization Considerations . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1 Normative References . . . . . . . . . . . . . . . . . . . 5 59 6.2 Informative References . . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 61 Intellectual Property and Copyright Statements . . . . . . . . 7 63 1. Introduction 65 1.1 Overview 67 The [NOTIFY] extension to the [SIEVE] mail filtering language is a 68 framework for providing notifications by employing URIs to specify 69 the notification mechanism. This document defines how xmpp URIs (see 70 [XMPP-URI]) are used to generate notifications via the Extensible 71 Messaging and Presence Protocol (see [XMPP]), also known as Jabber. 73 1.2 Terminology 75 This document inherits terminology from [NOTIFY], [SIEVE], and 76 [XMPP]. 78 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 79 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 80 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 81 interpreted as described in RFC 2119 [TERMS]. 83 2. Definition 85 The xmpp mechanism results in the sending of an XMPP message to 86 notify a recipient about an email message. The notification MUST be 87 an XMPP stanza. The value of the XMPP 'type' attribute 88 MUST be 'headline' or 'normal'. The value of the XMPP 'from' 89 attribute MUST be the XMPP address of the notification service. The 90 XMPP stanza MAY include a child element whose 91 value is either the ":subject" tag or, absent that, some configurable 92 text indicating that the message is a Sieve notification. 94 The format of the notify action is described in the following 95 sections. 97 2.1 Notify ":method" tag 99 The notify ":method" tag MUST be a URI that conforms to the xmpp URI 100 scheme (as specified in [XMPP-URI]) and that identifies an XMPP 101 account associated with the email inbox. The URI MAY include the 102 resource identifier portion of an XMPP address but SHOULD NOT include 103 an authority component, query component, or fragment identifier 104 component. The processing application MUST extract an XMPP address 105 from the URI in accordance with the processing rules specified in 106 [XMPP-URI]. The resulting XMPP address MUST be encapsulated in XMPP 107 syntax as the value of the XMPP 'to' attribute. 109 2.2 Notify ":priority" tag 111 The notify ":priority" tag has no special meaning for this 112 notification mechanism, and this specification puts no restriction on 113 its use. The value of the notify ":priority" tag MAY be transformed 114 into XMPP syntax; if so, it SHOULD be encapsulated as the value of an 115 [XMPP-SHIM] header named "Urgency", and the XML character of that 116 header SHOULD be "high", "medium", or "low". 118 3. Example 120 Consider the following Sieve notify action: 122 notify :method "xmpp:romeo@example.com" 123 :id "some-id" 124 :priority "high" 125 :message " Wherefore art thou?"; 127 The resulting XMPP stanza might be as follows: 129 132 A Sieve instant notification! 133 <juliet@example.org> Wherefore art thou? 134 135
urgent
136 137 139 4. Internationalization Considerations 141 Although an XMPP address may contain nearly any [UNICODE] character, 142 the value of the ":method" tag MUST be a Uniform Resource Identifier 143 (see [URI]) rather than an Internationalized Resource Identifier (see 144 [IRI]). The rules specified in [XMPP-URI] MUST be followed when 145 generating XMPP URIs. 147 5. Security Considerations 149 Detailed security considerations for the relevant protocols profiled 150 in this document are given in [NOTIFY], [SIEVE], and [XMPP]; this 151 document introduces no new security concerns above and beyond those 152 described in the foregoing specifications. 154 6. References 155 6.1 Normative References 157 [NOTIFY] Melnikov, A., "Sieve -- An extension for providing instant 158 notifications", draft-ietf-sieve-notify-01 (work in 159 progress), October 2005. 161 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 162 Language", draft-ietf-sieve-3028bis-05 (work in progress), 163 November 2005. 165 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, March 1997. 168 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 169 Protocol (XMPP): Core", RFC 3920, October 2004. 171 [XMPP-URI] 172 Saint-Andre, P., "Internationalized Resource Identifiers 173 (IRIs) and Uniform Resource Identifiers (URIs) for the 174 Extensible Messaging and Presence Protocol (XMPP)", 175 draft-saintandre-xmpp-iri-03 (work in progress), 176 December 2005. 178 6.2 Informative References 180 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 181 Identifiers (IRIs)", RFC 3987, January 2005. 183 [RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 184 10021 and RFC 822", RFC 1327, May 1992. 186 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 187 3.2.0", 2000. 189 The Unicode Standard, Version 3.2.0 is defined by The 190 Unicode Standard, Version 3.0 (Reading, MA, Addison- 191 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 192 Unicode Standard Annex #27: Unicode 3.1 193 (http://www.unicode.org/reports/tr27/) and by the Unicode 194 Standard Annex #28: Unicode 3.2 195 (http://www.unicode.org/reports/tr28/). 197 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 198 Resource Identifier (URI): Generic Syntax", STD 66, 199 RFC 3986, January 2005. 201 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 202 10646", STD 63, RFC 3629, November 2003. 204 [XMPP-SHIM] 205 Saint-Andre, P. and J. Hildebrand, "Stanza Headers and 206 Internet Metadata (SHIM)", JSF JEP 0131, August 2005. 208 Authors' Addresses 210 Peter Saint-Andre 211 Jabber Software Foundation 213 Email: stpeter@jabber.org 215 Alexey Melnikov 216 Isode Limited 218 Email: Alexey.Melnikov@isode.com 220 Intellectual Property Statement 222 The IETF takes no position regarding the validity or scope of any 223 Intellectual Property Rights or other rights that might be claimed to 224 pertain to the implementation or use of the technology described in 225 this document or the extent to which any license under such rights 226 might or might not be available; nor does it represent that it has 227 made any independent effort to identify any such rights. Information 228 on the procedures with respect to rights in RFC documents can be 229 found in BCP 78 and BCP 79. 231 Copies of IPR disclosures made to the IETF Secretariat and any 232 assurances of licenses to be made available, or the result of an 233 attempt made to obtain a general license or permission for the use of 234 such proprietary rights by implementers or users of this 235 specification can be obtained from the IETF on-line IPR repository at 236 http://www.ietf.org/ipr. 238 The IETF invites any interested party to bring to its attention any 239 copyrights, patents or patent applications, or other proprietary 240 rights that may cover technology that may be required to implement 241 this standard. Please address the information to the IETF at 242 ietf-ipr@ietf.org. 244 Disclaimer of Validity 246 This document and the information contained herein are provided on an 247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 249 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 250 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 251 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 254 Copyright Statement 256 Copyright (C) The Internet Society (2006). This document is subject 257 to the rights, licenses and restrictions contained in BCP 78, and 258 except as set forth therein, the authors retain all their rights. 260 Acknowledgment 262 Funding for the RFC Editor function is currently provided by the 263 Internet Society.