draft-ietf-sieve-notify-xmpp-08.txt   draft-ietf-sieve-notify-xmpp-09.txt 
Sieve Working Group P. Saint-Andre Sieve Working Group P. Saint-Andre
Internet-Draft XMPP Standards Foundation Internet-Draft XMPP Standards Foundation
Intended status: Standards Track A. Melnikov Intended status: Standards Track A. Melnikov
Expires: July 2, 2008 Isode Limited Expires: August 22, 2008 Isode Limited
December 30, 2007 February 19, 2008
Sieve Notification Mechanism: xmpp Sieve Notification Mechanism: xmpp
draft-ietf-sieve-notify-xmpp-08 draft-ietf-sieve-notify-xmpp-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2, 2008. This Internet-Draft will expire on August 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes a profile of the Sieve extension for This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent over the Extensible notifications, to allow notifications to be sent over the Extensible
Messaging and Presence Protocol (XMPP), also known as Jabber. Messaging and Presence Protocol (XMPP), also known as Jabber.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3.2. Action with body . . . . . . . . . . . . . . . . . . . . . 6 3.2. Action with body . . . . . . . . . . . . . . . . . . . . . 6
3.3. Action with body, importance, message, and subject . . . . 7 3.3. Action with body, importance, message, and subject . . . . 7
3.4. Action with from, message, importance, body, and 3.4. Action with from, message, importance, body, and
subject . . . . . . . . . . . . . . . . . . . . . . . . . 8 subject . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements Conformance . . . . . . . . . . . . . . . . . . . 9 4. Requirements Conformance . . . . . . . . . . . . . . . . . . . 9
5. Internationalization Considerations . . . . . . . . . . . . . 10 5. Internationalization Considerations . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
The [NOTIFY] extension to the [SIEVE] mail filtering language is a The [NOTIFY] extension to the [SIEVE] mail filtering language is a
framework for providing notifications by employing URIs to specify framework for providing notifications by employing URIs to specify
the notification mechanism. This document defines how xmpp URIs (see the notification mechanism. This document defines how xmpp URIs (see
[XMPP-URI]) are used to generate notifications via the Extensible [XMPP-URI]) are used to generate notifications via the Extensible
Messaging and Presence Protocol [XMPP], which is widely implemented Messaging and Presence Protocol [XMPP], which is widely implemented
skipping to change at page 3, line 48 skipping to change at page 3, line 48
MUST be encapsulated in XMPP syntax as the value of the XMPP 'to' MUST be encapsulated in XMPP syntax as the value of the XMPP 'to'
attribute. attribute.
2.2. Test notify_method_capability 2.2. Test notify_method_capability
In response to a notify_method_capability test for the "online" In response to a notify_method_capability test for the "online"
notification-capability, an implementation SHOULD return a value of notification-capability, an implementation SHOULD return a value of
"yes" if it has knowledge of an active presence session (see "yes" if it has knowledge of an active presence session (see
[XMPP-IM]) for the specified XMPP notification-uri; otherwise it [XMPP-IM]) for the specified XMPP notification-uri; otherwise it
SHOULD return a value of "maybe" (since typical XMPP systems may not SHOULD return a value of "maybe" (since typical XMPP systems may not
allow a SIEVE engine to gain knowledge about the presence of XMPP allow a Sieve engine to gain knowledge about the presence of XMPP
entities). entities).
2.3. Notify tag ":from" 2.3. Notify tag ":from"
If included, the ":from" tag MUST be an email address. The value of If included, the ":from" tag MUST be an electronic address that
conforms to the "Mailbox" rule defined in [RFC2821]. The value of
the ":from" tag MAY be included in the human-readable XML character the ":from" tag MAY be included in the human-readable XML character
data of the XMPP notification; alternatively or in addition, it MAY data of the XMPP notification; alternatively or in addition, it MAY
be transformed into formal XMPP syntax, in which case it MUST be be transformed into formal XMPP syntax, in which case it MUST be
encapsulated as the value of an XMPP Stanza Headers and Internet encapsulated as the value of an XMPP Stanza Headers and Internet
Metadata [SHIM] header named "Resent-From". Metadata [SHIM] header named "Resent-From".
2.4. Notify tag ":importance" 2.4. Notify tag ":importance"
The ":importance" tag has no special meaning for this notification The ":importance" tag has no special meaning for this notification
mechanism, and this specification puts no restriction on its use. mechanism, and this specification puts no restriction on its use.
skipping to change at page 4, line 48 skipping to change at page 4, line 49
implementation. implementation.
2.7. XMPP syntax 2.7. XMPP syntax
The xmpp mechanism results in the sending of an XMPP message to The xmpp mechanism results in the sending of an XMPP message to
notify a recipient about an email message. The general XMPP syntax notify a recipient about an email message. The general XMPP syntax
is as follows: is as follows:
o The notification MUST be an XMPP <message/> stanza. o The notification MUST be an XMPP <message/> stanza.
o The value of the XMPP 'from' attribute SHOULD be the XMPP address o The value of the XMPP 'from' attribute SHOULD be the XMPP address
of the notification service associated with the SIEVE engine or of the notification service associated with the Sieve engine or
the XMPP address of the entity to be notified. The value of the the XMPP address of the entity to be notified. The value of the
XMPP 'from' attribute MUST NOT be generated from the Sieve ":from" XMPP 'from' attribute MUST NOT be generated from the Sieve ":from"
tag. tag.
o The value of the XMPP 'to' attribute MUST be the XMPP address o The value of the XMPP 'to' attribute MUST be the XMPP address
specified in the XMPP URI contained in the "method" notify specified in the XMPP URI contained in the "method" notify
parameter. parameter.
o The value of the XMPP 'type' attribute MUST be 'headline' or o The value of the XMPP 'type' attribute MUST be 'headline' or
'normal'. 'normal'.
o The XMPP <message/> stanza MUST include a <body/> child element. o The XMPP <message/> stanza MUST include a <body/> child element.
skipping to change at page 5, line 51 skipping to change at page 5, line 51
be the envelope recipient address of the original email message be the envelope recipient address of the original email message
that triggered the notification. that triggered the notification.
3. Examples 3. Examples
In the following examples, the sender of the email has an address of In the following examples, the sender of the email has an address of
<mailto:juliet@example.org>, the entity to be notified has an email <mailto:juliet@example.org>, the entity to be notified has an email
address of <mailto:romeo@example.com> and an XMPP address of address of <mailto:romeo@example.com> and an XMPP address of
romeo@im.example.com (resulting in an XMPP URI of romeo@im.example.com (resulting in an XMPP URI of
<xmpp:romeo@im.example.com>), and the notification service associated <xmpp:romeo@im.example.com>), and the notification service associated
with the SIEVE engine has an XMPP address of notify.example.com. with the Sieve engine has an XMPP address of notify.example.com.
Note: In the following examples, line breaks are included in XMPP Note: In the following examples, line breaks are included in XMPP
URIs solely for the purpose of readability. URIs solely for the purpose of readability.
3.1. Basic action 3.1. Basic action
The following is a basic Sieve notify action with only a method. The The following is a basic Sieve notify action with only a method. The
XML character data of the XMPP <body/> and <subject/> elements are XML character data of the XMPP <body/> and <subject/> elements are
therefore generated by the Sieve engine based on configuration. In therefore generated by the Sieve engine based on configuration. In
addition, the Sieve engine includes a URI pointing to the message. addition, the Sieve engine includes a URI pointing to the message.
skipping to change at page 9, line 44 skipping to change at page 9, line 44
per character or byte for XMPP messages). Modification of per character or byte for XMPP messages). Modification of
characters themselves should not be necessary, since XMPP characters themselves should not be necessary, since XMPP
character data is encoded in [UTF-8]. character data is encoded in [UTF-8].
2. An implementation MAY ignore parameters specified in the 2. An implementation MAY ignore parameters specified in the
":from", ":importance", and ":options" tags. ":from", ":importance", and ":options" tags.
3. There is no recommended default message for an implementation to 3. There is no recommended default message for an implementation to
include if the ":message" argument is not specified. include if the ":message" argument is not specified.
4. A notification sent via the xmpp notification method MAY include 4. A notification sent via the xmpp notification method MAY include
a timestamp in the textual message. a timestamp in the textual message.
5. The value of the XMPP 'from' attribute MUST be the XMPP address 5. The value of the XMPP 'from' attribute MUST be the XMPP address
of the notification service associated with the SIEVE engine. of the notification service associated with the Sieve engine.
The value of the Sieve ":from" tag MAY be transformed into the The value of the Sieve ":from" tag MAY be transformed into the
value of an XMPP Stanza Headers and Internet Metadata [SHIM] value of an XMPP Stanza Headers and Internet Metadata [SHIM]
header named "Reply-To". header named "Reply-To".
6. The value of the XMPP 'to' attribute MUST be the XMPP address 6. The value of the XMPP 'to' attribute MUST be the XMPP address
specified in the XMPP URI contained in the "method" parameter. specified in the XMPP URI contained in the "method" parameter.
7. In accordance with [XMPP-URI], an implementation MUST ignore any 7. In accordance with [XMPP-URI], an implementation MUST ignore any
URI action or parameter it does not understand (i.e., the URI URI action or parameter it does not understand (i.e., the URI
MUST be processed as if the action or parameter were not MUST be processed as if the action or parameter were not
present). It is RECOMMENDED to support the XMPP "message" query present). It is RECOMMENDED to support the XMPP "message" query
skipping to change at page 10, line 26 skipping to change at page 10, line 26
8. An implementation MUST NOT include any other extraneous 8. An implementation MUST NOT include any other extraneous
information not specified in parameters to the notify action. information not specified in parameters to the notify action.
9. In response to a notify_method_capability test for the "online" 9. In response to a notify_method_capability test for the "online"
notification-capability, an implementation SHOULD return a value notification-capability, an implementation SHOULD return a value
of "yes" if it has knowledge of an active presence session (see of "yes" if it has knowledge of an active presence session (see
[XMPP-IM]) for the specified XMPP notification-uri but only if [XMPP-IM]) for the specified XMPP notification-uri but only if
the entity that requested the test is authorized to know the the entity that requested the test is authorized to know the
presence of the associated XMPP entity (e.g., via explicit presence of the associated XMPP entity (e.g., via explicit
presence subscription as specified in [XMPP-IM]); otherwise it presence subscription as specified in [XMPP-IM]); otherwise it
SHOULD return a value of "maybe" (since typical XMPP systems may SHOULD return a value of "maybe" (since typical XMPP systems may
not allow a SIEVE engine to gain knowledge about the presence of not allow a Sieve engine to gain knowledge about the presence of
XMPP entities). XMPP entities).
10. An implementation SHOULD NOT attempt to retry delivery of a 10. An implementation SHOULD NOT attempt to retry delivery of a
notification if it receives an XMPP error of type "auth" or notification if it receives an XMPP error of type "auth" or
"cancel", MAY attempt to retry delivery if it receives an XMPP "cancel", MAY attempt to retry delivery if it receives an XMPP
error of type "wait", and MAY attempt to retry delivery if it error of type "wait", and MAY attempt to retry delivery if it
receives an XMPP error of "modify" but only if it makes receives an XMPP error of "modify" but only if it makes
appropriate modifications to the notification (see [XMPP]); in appropriate modifications to the notification (see [XMPP]); in
any case the number of retries SHOULD be limited to a any case the number of retries SHOULD be limited to a
configurable number no less than 3 and no more than 10. An configurable number no less than 3 and no more than 10. An
implementation MAY throttle notifications if the number of implementation MAY throttle notifications if the number of
skipping to change at page 11, line 23 skipping to change at page 11, line 23
[NOTIFY] specifies that a notification method MUST provide mechanisms [NOTIFY] specifies that a notification method MUST provide mechanisms
for avoiding notification loops. One type of notification loop can for avoiding notification loops. One type of notification loop can
be caused by message forwarding; however, such loops are prevented be caused by message forwarding; however, such loops are prevented
because XMPP does not support forwarding of messages from one XMPP because XMPP does not support forwarding of messages from one XMPP
address to another. Another type of notification loop can be caused address to another. Another type of notification loop can be caused
by auto-replies to XMPP messages received by the XMPP notification by auto-replies to XMPP messages received by the XMPP notification
service associated with the Sieve engine; therefore such a service service associated with the Sieve engine; therefore such a service
MUST NOT auto-reply to XMPP messages it receives. MUST NOT auto-reply to XMPP messages it receives.
The XMPP notification service associated with a Sieve engine MUST NOT A common use case might be for a user to create a script that enables
leak presence (network availability) information regarding users of the Sieve engine to act differently if the user is currently
the service. In particular, the service MUST NOT reveal presence available at a particular type of service (e.g., send notifications
information via a notify_method_capability test to entities that are to the user's XMPP address if the user has an active session at an
not authorized to know such information (e.g., via a presence XMPP service). Whether the user is currently available can be
subscription as specified in [XMPP-IM]). determined by means of a notify_method_capability test for the
"online" notification-capability. In XMPP, information about current
network availability is called "presence" (see also [MODEL]). Since
[XMPP-IM] requires that a user must approve a presence subscription
before an entity can gain access to the user's presence information,
a limited but reasonably safe implementation might be for the Sieve
engine to request a subscription to the user's presence. The user
would then need to approve that subscription request so that the
Sieve engine can act appropriately depending on whether the user is
online or offline. However, the Sieve engine MUST NOT use the user's
presence information when processing scripts on behalf of a script
owner other than the user, unless the Sieve engine has explicit
knowledge (e.g., via integration with an XMPP server's presence
authorization rules) that the script owner is authorized to know the
user's presence. While it would be possible to design a more
advanced approach to delegation of presence authorization, any such
approach is left to future standards work.
7. IANA Considerations 7. IANA Considerations
The following template provides the IANA registration of the Sieve The following template provides the IANA registration of the Sieve
notification mechanism specified in this document: notification mechanism specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve notification mechanism Subject: Registration of new Sieve notification mechanism
Mechanism name: xmpp Mechanism name: xmpp
Mechanism URI: draft-saintandre-rfc4622bis Mechanism URI: draft-saintandre-rfc4622bis
skipping to change at page 12, line 8 skipping to change at page 12, line 23
This information should be added to the list of Sieve notification This information should be added to the list of Sieve notification
mechanisms maintained at mechanisms maintained at
<http://www.iana.org/assignments/sieve-notification>. <http://www.iana.org/assignments/sieve-notification>.
8. References 8. References
8.1. Normative References 8.1. Normative References
[NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
"SIEVE Email Filtering: Notifications", "Sieve Email Filtering: Notifications",
draft-ietf-sieve-notify-10 (work in progress), draft-ietf-sieve-notify-12 (work in progress),
November 2007. December 2007.
[OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066, [OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066,
August 2006. August 2006.
[QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF [QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF
XEP 0147, September 2006. XEP 0147, September 2006.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and [SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and
Internet Metadata", XSF XEP 0131, July 2006. Internet Metadata", XSF XEP 0131, July 2006.
[SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering
Language", draft-ietf-sieve-3028bis-13 (work in progress), Language", draft-ietf-sieve-3028bis-13 (work in progress),
October 2007. October 2007.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 12, line 48 skipping to change at page 13, line 18
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[IMAP-URL] [IMAP-URL]
Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
November 2007. November 2007.
[MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[POP-URL] Gellens, R., "POP URL Scheme", RFC 2384, August 1998. [POP-URL] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
3.2.0", 2000. 3.2.0", 2000.
The Unicode Standard, Version 3.2.0 is defined by The The Unicode Standard, Version 3.2.0 is defined by The
Unicode Standard, Version 3.0 (Reading, MA, Addison- Unicode Standard, Version 3.0 (Reading, MA, Addison-
skipping to change at page 14, line 7 skipping to change at page 15, line 7
Email: stpeter@jabber.org Email: stpeter@jabber.org
URI: https://stpeter.im/ URI: https://stpeter.im/
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 16 change blocks. 
24 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/