Network Working Group P. Saint-Andre
Request for Comments: 5437 Cisco
Category: Standards Track A. Melnikov
Isode Limited
January 2009
Sieve Notification Mechanism:
Extensible Messaging and Presence Protocol (XMPP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent over the Extensible
Messaging and Presence Protocol (XMPP), also known as Jabber.
Saint-Andre & Melnikov Standards Track [Page 1]
RFC 5437 Sieve Notify Method: XMPP January 2009
Table of Contents
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Terminology ................................................3
2. Definition ......................................................3
2.1. Notify Parameter "method" ..................................3
2.2. Test notify_method_capability ..............................3
2.3. Notify Tag ":from" .........................................4
2.4. Notify Tag ":importance" ...................................4
2.5. Notify Tag ":message" ......................................4
2.6. Notify Tag ":options" ......................................4
2.7. XMPP Syntax ................................................4
3. Examples ........................................................6
3.1. Basic Action ...............................................6
3.2. Action with "body" .........................................7
3.3. Action with "body", ":importance", ":message", and
"subject" ..................................................7
3.4. Action with ":from", ":message", ":importance",
"body", and "subject" ......................................8
4. Requirements Conformance ........................................9
5. Internationalization Considerations ............................10
6. Security Considerations ........................................11
7. IANA Considerations ............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
Saint-Andre & Melnikov Standards Track [Page 2]
RFC 5437 Sieve Notify Method: XMPP January 2009
1. Introduction
1.1. Overview
The [NOTIFY] extension to the [SIEVE] mail filtering language is a
framework for providing notifications by employing URIs to specify
the notification mechanism. This document defines how xmpp URIs (see
[XMPP-URI]) are used to generate notifications via the Extensible
Messaging and Presence Protocol [XMPP], which is widely implemented
in Jabber instant messaging technologies.
1.2. Terminology
This document inherits terminology from [NOTIFY], [SIEVE], and
[XMPP]. In particular, the terms "parameter" and "tag" are used as
described in [NOTIFY] to refer to aspects of Sieve scripts, and the
term "key" is used as described in [XMPP-URI] to refer to aspects of
an XMPP URI.
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [TERMS].
2. Definition
2.1. Notify Parameter "method"
The "method" parameter MUST be a URI that conforms to the xmpp URI
scheme (as specified in [XMPP-URI]) and that identifies an XMPP
account associated with the email inbox. The URI MAY include the
resource identifier of an XMPP address and/or the query component
portion of an XMPP URI, but SHOULD NOT include an authority component
or fragment identifier component. The processing application MUST
extract an XMPP address from the URI in accordance with the
processing rules specified in [XMPP-URI]. The resulting XMPP address
MUST be encapsulated in XMPP syntax as the value of the XMPP 'to'
attribute.
2.2. Test notify_method_capability
In response to a notify_method_capability test for the "online"
notification-capability, an implementation SHOULD return a value of
"yes" if it has knowledge of an active presence session (see
[XMPP-IM]) for the specified XMPP notification-uri; otherwise, it
SHOULD return a value of "maybe" (since typical XMPP systems may not
allow a Sieve engine to gain knowledge about the presence of XMPP
entities).
Saint-Andre & Melnikov Standards Track [Page 3]
RFC 5437 Sieve Notify Method: XMPP January 2009
2.3. Notify Tag ":from"
If included, the ":from" tag MUST be an electronic address that
conforms to the "Mailbox" rule defined in [RFC5321]. The value of
the ":from" tag MAY be included in the human-readable XML character
data of the XMPP notification; alternatively or in addition, it MAY
be transformed into formal XMPP syntax, in which case it MUST be
encapsulated as the value of an XMPP SHIM (Stanza Headers and
Internet Metadata) [SHIM] header named "Resent-From".
2.4. Notify Tag ":importance"
The ":importance" tag has no special meaning for this notification
mechanism, and this specification puts no restriction on its use.
The value of the ":importance" tag MAY be transformed into XMPP
syntax (in addition to or instead of including appropriate text in
the XML character data of the XMPP element); if so, it SHOULD
be encapsulated as the value of an XMPP SHIM (Stanza Headers and
Internet Metadata) [SHIM] header named "Urgency", where the XML
character of that header is "high" if the value of the ":importance"
tag is "1", "medium" if the value of the ":importance" tag is "2",
and "low" if the value of the ":importance" tag is "3".
2.5. Notify Tag ":message"
If the ":message" tag is included, that string MUST be transformed
into the XML character data of an XMPP
RFC, FYI, BCP