7Network Working Group P. Saint-Andre
8Request for Comments: 5437 Cisco
9Category: Standards Track A. Melnikov
14 Sieve Notification Mechanism:
15 Extensible Messaging and Presence Protocol (XMPP)
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (c) 2009 IETF Trust and the persons identified as the
28 document authors. All rights reserved.
30 This document is subject to BCP 78 and the IETF Trust's Legal
31 Provisions Relating to IETF Documents (http://trustee.ietf.org/
32 license-info) in effect on the date of publication of this document.
33 Please review these documents carefully, as they describe your rights
34 and restrictions with respect to this document.
38 This document describes a profile of the Sieve extension for
39 notifications, to allow notifications to be sent over the Extensible
40 Messaging and Presence Protocol (XMPP), also known as Jabber.
58Saint-Andre & Melnikov Standards Track [Page 1]
60RFC 5437 Sieve Notify Method: XMPP January 2009
65 1. Introduction ....................................................3
66 1.1. Overview ...................................................3
67 1.2. Terminology ................................................3
68 2. Definition ......................................................3
69 2.1. Notify Parameter "method" ..................................3
70 2.2. Test notify_method_capability ..............................3
71 2.3. Notify Tag ":from" .........................................4
72 2.4. Notify Tag ":importance" ...................................4
73 2.5. Notify Tag ":message" ......................................4
74 2.6. Notify Tag ":options" ......................................4
75 2.7. XMPP Syntax ................................................4
76 3. Examples ........................................................6
77 3.1. Basic Action ...............................................6
78 3.2. Action with "body" .........................................7
79 3.3. Action with "body", ":importance", ":message", and
80 "subject" ..................................................7
81 3.4. Action with ":from", ":message", ":importance",
82 "body", and "subject" ......................................8
83 4. Requirements Conformance ........................................9
84 5. Internationalization Considerations ............................10
85 6. Security Considerations ........................................11
86 7. IANA Considerations ............................................12
87 8. References .....................................................12
88 8.1. Normative References ......................................12
89 8.2. Informative References ....................................13
114Saint-Andre & Melnikov Standards Track [Page 2]
116RFC 5437 Sieve Notify Method: XMPP January 2009
123 The [NOTIFY] extension to the [SIEVE] mail filtering language is a
124 framework for providing notifications by employing URIs to specify
125 the notification mechanism. This document defines how xmpp URIs (see
126 [XMPP-URI]) are used to generate notifications via the Extensible
127 Messaging and Presence Protocol [XMPP], which is widely implemented
128 in Jabber instant messaging technologies.
132 This document inherits terminology from [NOTIFY], [SIEVE], and
133 [XMPP]. In particular, the terms "parameter" and "tag" are used as
134 described in [NOTIFY] to refer to aspects of Sieve scripts, and the
135 term "key" is used as described in [XMPP-URI] to refer to aspects of
138 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
139 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
140 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
141 interpreted as described in [TERMS].
1452.1. Notify Parameter "method"
147 The "method" parameter MUST be a URI that conforms to the xmpp URI
148 scheme (as specified in [XMPP-URI]) and that identifies an XMPP
149 account associated with the email inbox. The URI MAY include the
150 resource identifier of an XMPP address and/or the query component
151 portion of an XMPP URI, but SHOULD NOT include an authority component
152 or fragment identifier component. The processing application MUST
153 extract an XMPP address from the URI in accordance with the
154 processing rules specified in [XMPP-URI]. The resulting XMPP address
155 MUST be encapsulated in XMPP syntax as the value of the XMPP 'to'
1582.2. Test notify_method_capability
160 In response to a notify_method_capability test for the "online"
161 notification-capability, an implementation SHOULD return a value of
162 "yes" if it has knowledge of an active presence session (see
163 [XMPP-IM]) for the specified XMPP notification-uri; otherwise, it
164 SHOULD return a value of "maybe" (since typical XMPP systems may not
165 allow a Sieve engine to gain knowledge about the presence of XMPP
170Saint-Andre & Melnikov Standards Track [Page 3]
172RFC 5437 Sieve Notify Method: XMPP January 2009
1752.3. Notify Tag ":from"
177 If included, the ":from" tag MUST be an electronic address that
178 conforms to the "Mailbox" rule defined in [RFC5321]. The value of
179 the ":from" tag MAY be included in the human-readable XML character
180 data of the XMPP notification; alternatively or in addition, it MAY
181 be transformed into formal XMPP syntax, in which case it MUST be
182 encapsulated as the value of an XMPP SHIM (Stanza Headers and
183 Internet Metadata) [SHIM] header named "Resent-From".
1852.4. Notify Tag ":importance"
187 The ":importance" tag has no special meaning for this notification
188 mechanism, and this specification puts no restriction on its use.
189 The value of the ":importance" tag MAY be transformed into XMPP
190 syntax (in addition to or instead of including appropriate text in
191 the XML character data of the XMPP <body/> element); if so, it SHOULD
192 be encapsulated as the value of an XMPP SHIM (Stanza Headers and
193 Internet Metadata) [SHIM] header named "Urgency", where the XML
194 character of that header is "high" if the value of the ":importance"
195 tag is "1", "medium" if the value of the ":importance" tag is "2",
196 and "low" if the value of the ":importance" tag is "3".
1982.5. Notify Tag ":message"
200 If the ":message" tag is included, that string MUST be transformed
201 into the XML character data of an XMPP <body/> element (where the
202 string is generated according to the guidelines specified in Section
2052.6. Notify Tag ":options"
207 The ":options" tag has no special meaning for this notification
208 mechanism. Any handling of this tag is the responsibility of an
213 The xmpp mechanism results in the sending of an XMPP message to
214 notify a recipient about an email message. The general XMPP syntax
217 o The notification MUST be an XMPP <message/> stanza.
226Saint-Andre & Melnikov Standards Track [Page 4]
228RFC 5437 Sieve Notify Method: XMPP January 2009
231 o The value of the XMPP 'from' attribute SHOULD be the XMPP address
232 of the notification service associated with the Sieve engine or
233 the XMPP address of the entity to be notified. The value of the
234 XMPP 'from' attribute MUST NOT be generated from the Sieve ":from"
237 o The value of the XMPP 'to' attribute MUST be the XMPP address
238 specified in the XMPP URI contained in the "method" notify
241 o The value of the XMPP 'type' attribute MUST be 'headline' or
244 o The XMPP <message/> stanza MUST include a <body/> child element.
245 If the ":message" tag is included in the Sieve script, that string
246 MUST be used as the XML character data of the <body/> element. If
247 not and if the XMPP URI contained in the "method" notify parameter
248 specified a "body" key in the query component, that value SHOULD
249 be used. Otherwise, the XML character data SHOULD be some
250 configurable text indicating that the message is a Sieve
253 o The XMPP <message/> stanza MAY include a <subject/> child element.
254 If the XMPP URI contained in the "method" notify parameter
255 specified a "subject" key in the query component, that value
256 SHOULD be used as the XML character data of the <subject/>
257 element. Otherwise, the XML character data SHOULD be some
258 configurable text indicating that the message is a Sieve
261 o The XMPP <message/> stanza SHOULD include a URI, for the recipient
262 to use as a hint in locating the message, encapsulated as the XML
263 character data of a <url/> child element of an <x/> element
264 qualified by the 'jabber:x:oob' namespace, as specified in [OOB].
265 If included, the URI SHOULD be an Internet Message Access Protocol
266 [IMAP] URL that specifies the location of the message, as defined
267 in [IMAP-URL], but MAY be another URI type that can specify or
268 hint at the location of an email message, such as a URI for an
269 HTTP resource [HTTP] or a Post Office Protocol Version 3 (POP3)
270 mailbox [POP-URL] at which the message can be accessed. It is not
271 expected that an XMPP user agent shall directly handle such a URI,
272 but instead that it shall invoke an appropriate helper application
275 o The XMPP <message/> stanza MAY include an XMPP SHIM (Stanza
276 Headers and Internet Metadata) [SHIM] header named "Resent-From".
277 If the Sieve script included a ":from" tag, the "Resent-From"
282Saint-Andre & Melnikov Standards Track [Page 5]
284RFC 5437 Sieve Notify Method: XMPP January 2009
287 value MUST be the value of the ":from" tag; otherwise, the
288 "Resent-From" value SHOULD be the envelope recipient address of
289 the original email message that triggered the notification.
293 In the following examples, the sender of the email has an address of
294 <mailto:juliet@example.org>, the entity to be notified has an email
295 address of <mailto:romeo@example.com> and an XMPP address of
296 romeo@im.example.com (resulting in an XMPP URI of
297 <xmpp:romeo@im.example.com>), and the notification service associated
298 with the Sieve engine has an XMPP address of notify.example.com.
300 Note: In the following examples, line breaks are included in XMPP
301 URIs solely for the purpose of readability.
305 The following is a basic Sieve notify action with only a method. The
306 XML character data of the XMPP <body/> and <subject/> elements are
307 therefore generated by the Sieve engine based on configuration. In
308 addition, the Sieve engine includes a URI pointing to the message.
310 Basic action (Sieve syntax)
312 notify "xmpp:romeo@im.example.com"
314 The resulting XMPP <message/> stanza might be as follows:
316 Basic action (XMPP syntax)
318 <message from='notify.example.com'
319 to='romeo@im.example.com'
322 <subject>SIEVE</subject>
323 <body><juliet@example.com> You got mail.</body>
324 <x xmlns='jabber:x:oob'>
326 imap://romeo@example.com/INBOX;UIDVALIDITY=385759043/;UID=18
338Saint-Andre & Melnikov Standards Track [Page 6]
340RFC 5437 Sieve Notify Method: XMPP January 2009
3433.2. Action with "body"
345 The following action contains a "body" key in the query component of
346 the XMPP URI but no ":message" tag in the Sieve script. As a result,
347 the XML character data of the XMPP <body/> element in the XMPP
348 notification is taken from the XMPP URI. In addition, the Sieve
349 engine includes a URI pointing to the message.
351 Action with "body" (Sieve syntax)
353 notify "xmpp:romeo@im.example.com?message
354 ;body=Wherefore%20art%20thou%3F"
356 The resulting XMPP <message/> stanza might be as follows.
358 Action with "body" (XMPP syntax)
360 <message from='notify.example.com'
361 to='romeo@im.example.com'
364 <subject>SIEVE</subject>
365 <body>Wherefore art thou?</body>
366 <x xmlns='jabber:x:oob'>
368 imap://romeo@example.com/INBOX;UIDVALIDITY=385759044/;UID=19
3733.3. Action with "body", ":importance", ":message", and "subject"
375 The following action specifies an ":importance" tag and a ":message"
376 tag in the Sieve script, as well as a "body" key and a "subject" key
377 in the query component of the XMPP URI. As a result, the ":message"
378 tag from the Sieve script overrides the "body" key from the XMPP URI
379 when generating the XML character data of the XMPP <body/> element.
380 In addition, the Sieve engine includes a URI pointing to the message.
382 Action with "body", ":importance", ":message", and "subject" (Sieve
385 notify :importance "1"
386 :message "Contact Juliet immediately!"
387 "xmpp:romeo@im.example.com?message
388 ;body=You%27re%20in%20trouble
394Saint-Andre & Melnikov Standards Track [Page 7]
396RFC 5437 Sieve Notify Method: XMPP January 2009
399 The resulting XMPP <message/> stanza might be as follows.
401 Action with "body", ":importance", ":message", and "subject" (XMPP
404 <message from='notify.example.com'
405 to='romeo@im.example.com'
408 <subject>ALERT!</subject>
409 <body>Contact Juliet immediately!</body>
410 <headers xmlns='http://jabber.org/protocol/shim'>
411 <header name='Urgency'>high</header>
413 <x xmlns='jabber:x:oob'>
415 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20
4203.4. Action with ":from", ":message", ":importance", "body", and
423 The following action specifies a ":from" tag, an ":importance" tag,
424 and a ":message" tag in the Sieve script, as well as a "body" key and
425 a "subject" key in the query component of the XMPP URI. As a result,
426 the ":message" tag from the Sieve script overrides the "body" key
427 from the XMPP URI when generating the XML character data of the XMPP
428 <body/> element. In addition, the Sieve engine includes a URI
429 pointing to the message, as well as an XMPP SHIM (Stanza Headers and
430 Internet Metadata) [SHIM] header named "Resent-From" (which
431 encapsulates the value of the ":from" tag).
433 Action with ":from", ":importance", ":message", "body", and "subject"
436 notify :from "romeo.my.romeo@example.com"
438 :message "Contact Juliet immediately!"
439 "xmpp:romeo@im.example.com?message
440 ;body=You%27re%20in%20trouble
443 The resulting XMPP <message/> stanza might be as follows.
450Saint-Andre & Melnikov Standards Track [Page 8]
452RFC 5437 Sieve Notify Method: XMPP January 2009
455 Action with ":from", ":importance", ":message", "body", and "subject"
458 <message from='notify.example.com'
459 to='romeo@im.example.com'
462 <subject>ALERT!</subject>
463 <body>Contact Juliet immediately!</body>
464 <headers xmlns='http://jabber.org/protocol/shim'>
465 <header name='Resent-From'>romeo.my.romeo@example.com</header>
466 <header name='Urgency'>high</header>
468 <x xmlns='jabber:x:oob'>
470 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=21
4754. Requirements Conformance
477 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve
478 notification methods. The conformance of the xmpp notification
479 mechanism is provided here.
481 1. An implementation of the xmpp notification method SHOULD NOT
482 modify the final notification text (e.g., to limit the length);
483 however, a given deployment MAY do so (e.g., if recipients pay
484 per character or byte for XMPP messages). Modification of
485 characters themselves should not be necessary, since XMPP
486 character data is encoded in [UTF-8].
488 2. An implementation MAY ignore parameters specified in the
489 ":from", ":importance", and ":options" tags.
491 3. There is no recommended default message for an implementation to
492 include if the ":message" tag is not specified.
494 4. A notification sent via the xmpp notification method MAY include
495 a timestamp in the textual message.
497 5. The value of the XMPP 'from' attribute MUST be the XMPP address
498 of the notification service associated with the Sieve engine.
499 The value of the Sieve ":from" tag MAY be transformed into the
500 value of an XMPP SHIM (Stanza Headers and Internet Metadata)
501 [SHIM] header named "Resent-From".
506Saint-Andre & Melnikov Standards Track [Page 9]
508RFC 5437 Sieve Notify Method: XMPP January 2009
511 6. The value of the XMPP 'to' attribute MUST be the XMPP address
512 specified in the XMPP URI contained in the "method" parameter.
514 7. In accordance with [XMPP-URI], an implementation MUST ignore any
515 URI action or key it does not understand (i.e., the URI MUST be
516 processed as if the action or key were not present). It is
517 RECOMMENDED to support the XMPP "message" query type (see
518 [QUERIES]) and the associated "body" and "subject" keys, which
519 SHOULD be mapped to the XMPP <body/> and <subject/> child
520 elements of the XMPP <message/> stanza, respectively. However,
521 if included, then the Sieve notify ":message" tag MUST be mapped
522 to the XMPP <body/> element, overriding the "body" key (if any)
523 included in the XMPP URI.
525 8. An implementation MUST NOT include any other extraneous
526 information not specified in parameters to the notify action.
528 9. In response to a notify_method_capability test for the "online"
529 notification-capability, an implementation SHOULD return a value
530 of "yes" if it has knowledge of an active presence session (see
531 [XMPP-IM]) for the specified XMPP notification-uri, but only if
532 the entity that requested the test is authorized to know the
533 presence of the associated XMPP entity (e.g., via explicit
534 presence subscription as specified in [XMPP-IM]); otherwise, it
535 SHOULD return a value of "maybe" (since typical XMPP systems may
536 not allow a Sieve engine to gain knowledge about the presence of
539 10. An implementation SHOULD NOT attempt to retry delivery of a
540 notification if it receives an XMPP error of type "auth" or
541 "cancel", MAY attempt to retry delivery if it receives an XMPP
542 error of type "wait", and MAY attempt to retry delivery if it
543 receives an XMPP error of "modify", but only if it makes
544 appropriate modifications to the notification (see [XMPP]); in
545 any case, the number of retries SHOULD be limited to a
546 configurable number no less than 3 and no more than 10. An
547 implementation MAY throttle notifications if the number of
548 notifications within a given time period becomes excessive
549 according to local service policy. Duplicate suppression (if
550 any) is a matter of implementation and is not specified herein.
5525. Internationalization Considerations
554 Although an XMPP address may contain nearly any [UNICODE] character,
555 the value of the "method" parameter MUST be a Uniform Resource
556 Identifier (see [URI]) rather than an Internationalized Resource
557 Identifier (see [IRI]). The rules specified in [XMPP-URI] MUST be
558 followed when generating XMPP URIs.
562Saint-Andre & Melnikov Standards Track [Page 10]
564RFC 5437 Sieve Notify Method: XMPP January 2009
567 In accordance with Section 13 of RFC 3920, all data sent over XMPP
568 MUST be encoded in [UTF-8].
5706. Security Considerations
572 Depending on the information included, sending a notification can be
573 comparable to forwarding mail to the notification recipient. Care
574 must be taken when forwarding mail automatically, to ensure that
575 confidential information is not sent into an insecure environment.
576 In particular, implementations MUST conform to the security
577 considerations given in [NOTIFY], [SIEVE], and [XMPP].
579 [NOTIFY] specifies that a notification method MUST provide mechanisms
580 for avoiding notification loops. One type of notification loop can
581 be caused by message forwarding; however, such loops are prevented
582 because XMPP does not support the forwarding of messages from one
583 XMPP address to another. Another type of notification loop can be
584 caused by auto-replies to XMPP messages received by the XMPP
585 notification service associated with the Sieve engine; therefore,
586 such a service MUST NOT auto-reply to XMPP messages it receives.
588 A common use case might be for a user to create a script that enables
589 the Sieve engine to act differently if the user is currently
590 available at a particular type of service (e.g., send notifications
591 to the user's XMPP address if the user has an active session at an
592 XMPP service). Whether the user is currently available can be
593 determined by means of a notify_method_capability test for the
594 "online" notification-capability. In XMPP, information about current
595 network availability is called "presence" (see also [MODEL]). Since
596 [XMPP-IM] requires that a user must approve a presence subscription
597 before an entity can gain access to the user's presence information,
598 a limited but reasonably safe implementation might be for the Sieve
599 engine to request a subscription to the user's presence. The user
600 would then need to approve that subscription request so that the
601 Sieve engine can act appropriately depending on whether the user is
602 online or offline. However, the Sieve engine MUST NOT use the user's
603 presence information when processing scripts on behalf of a script
604 owner other than the user, unless the Sieve engine has explicit
605 knowledge (e.g., via integration with an XMPP server's presence
606 authorization rules) that the script owner is authorized to know the
607 user's presence. While it would be possible to design a more
608 advanced approach to the delegation of presence authorization, any
609 such approach is left to future standards work.
618Saint-Andre & Melnikov Standards Track [Page 11]
620RFC 5437 Sieve Notify Method: XMPP January 2009
6237. IANA Considerations
625 The following template provides the IANA registration of the Sieve
626 notification mechanism specified in this document:
629 Subject: Registration of new Sieve notification mechanism
631 Mechanism URI: RFC 5122 [XMPP-URI]
632 Mechanism-specific options: none
633 Permanent and readily available reference: RFC 5437
634 Person and email address to contact for further information:
635 Peter Saint-Andre <registrar@xmpp.org>
637 This information has been added to the list of Sieve notification
638 mechanisms maintained at <http://www.iana.org>.
6428.1. Normative References
644 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
645 Martin, "Sieve Email Filtering: Extension for
646 Notifications", RFC 5435, January 2009.
648 [OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066,
651 [QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF
652 XEP 0147, September 2006.
654 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
657 [SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and
658 Internet Metadata", XSF XEP 0131, July 2006.
660 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
661 Filtering Language", RFC 5228, January 2008.
663 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
664 Requirement Levels", BCP 14, RFC 2119, March 1997.
666 [XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers
667 (IRIs) and Uniform Resource Identifiers (URIs) for the
668 Extensible Messaging and Presence Protocol (XMPP)",
669 RFC 5122, February 2008.
674Saint-Andre & Melnikov Standards Track [Page 12]
676RFC 5437 Sieve Notify Method: XMPP January 2009
6798.2. Informative References
681 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
682 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
683 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
685 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
686 4rev1", RFC 3501, March 2003.
688 [IMAP-URL] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
691 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
692 Identifiers (IRIs)", RFC 3987, January 2005.
694 [MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
695 Presence and Instant Messaging", RFC 2778, February 2000.
697 [POP-URL] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
699 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
702 The Unicode Standard, Version 3.2.0 is defined by The
703 Unicode Standard, Version 3.0 (Reading, MA, Addison-
704 Wesley, 2000. ISBN 0-201-61633-5), as amended by the
705 Unicode Standard Annex #27: Unicode 3.1
706 (http://www.unicode.org/reports/tr27/) and by the Unicode
707 Standard Annex #28: Unicode 3.2
708 (http://www.unicode.org/reports/tr28/).
710 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
711 Resource Identifier (URI): Generic Syntax", STD 66,
712 RFC 3986, January 2005.
714 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
715 10646", STD 63, RFC 3629, November 2003.
717 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence
718 Protocol (XMPP): Core", RFC 3920, October 2004.
720 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
721 Protocol (XMPP): Instant Messaging and Presence",
722 RFC 3921, October 2004.
730Saint-Andre & Melnikov Standards Track [Page 13]
732RFC 5437 Sieve Notify Method: XMPP January 2009
740 EMail: psaintan@cisco.com
746 EMail: Alexey.Melnikov@isode.com
786Saint-Andre & Melnikov Standards Track [Page 14]