draft-ietf-sieve-notify-xmpp-05.txt   draft-ietf-sieve-notify-xmpp-06.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: April 3, 2008 Isode Limited Expires: May 10, 2008 Isode Limited
October 1, 2007 November 7, 2007
Sieve Notification Mechanism: xmpp Sieve Notification Mechanism: xmpp
draft-ietf-sieve-notify-xmpp-05 draft-ietf-sieve-notify-xmpp-06
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 April 3, 2008. This Internet-Draft will expire on May 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Notify parameter "method" . . . . . . . . . . . . . . . . 3 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . 4
2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . 4 2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . 4
2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . 4 2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . 4
2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . 4 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . 4
2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . 4 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . 4
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements Conformance . . . . . . . . . . . . . . . . . . . 5 4. Requirements Conformance . . . . . . . . . . . . . . . . . . . 6
5. Internationalization Considerations . . . . . . . . . . . . . 7 5. Internationalization Considerations . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11
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 (see [XMPP]), which is widely Messaging and Presence Protocol (see [XMPP]), which is widely
skipping to change at page 3, line 36 skipping to change at page 3, line 36
2. Definition 2. Definition
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 'type' attribute MUST be 'headline' or o The value of the XMPP 'type' attribute MUST be 'headline' or
'normal'. 'normal'.
o The value of the XMPP 'from' attribute MUST be the XMPP address of o The value of the XMPP 'from' attribute MUST be the XMPP address of
the notification service. the notification service associated with the SIEVE engine.
o The XMPP <message/> stanza MAY include a <subject/> child element o The XMPP <message/> stanza MAY include a <subject/> child element
whose value is some configurable text indicating that the message whose value is some configurable text indicating that the message
is a Sieve notification. is a Sieve notification.
o The notification SHOULD include a URL for the recipient to use as o The notification SHOULD include a URI for the recipient to use as
a hint in locating the message, encapsulated as the XML character a hint in locating the message, encapsulated as the XML character
data of a <url/> child element of an <x/> element qualified by the data of a <url/> child element of an <x/> element qualified by the
'jabber:x:oob' namespace as specified in [OOB]. 'jabber:x:oob' namespace as specified in [OOB]. If included, the
URI SHOULD be an Internet Message Access Protocol [IMAP] URL that
specifies the location of the message as defined in [IMAP-URL],
but MAY be another URI type that can specify or hint at the
location of an email message, such as a URI for an HTTP resource
[HTTP] or a POP3 mailbox [POP-URL] at which the message can be
accessed. It is not expected that an XMPP user agent shall
directly handle such a URI, but instead that it shall invoke an
appropriate helper application to handle the URI.
The recommended mapping of the Sieve notify action into XMPP syntax The recommended mapping of the Sieve notify action into XMPP syntax
is described in the following sections. is described in the following sections.
2.1. Notify parameter "method" 2.1. Notify parameter "method"
The "method" parameter MUST be a URI that conforms to the xmpp URI The "method" parameter MUST be a URI that conforms to the xmpp URI
scheme (as specified in [XMPP-URI]) and that identifies an XMPP scheme (as specified in [XMPP-URI]) and that identifies an XMPP
account associated with the email inbox. The URI MAY include the account associated with the email inbox. The URI MAY include the
resource identifier portion of an XMPP address but SHOULD NOT include resource identifier portion of an XMPP address but SHOULD NOT include
skipping to change at page 4, line 18 skipping to change at page 4, line 26
from the URI in accordance with the processing rules specified in from the URI in accordance with the processing rules specified in
[XMPP-URI]. The resulting XMPP address MUST be encapsulated in XMPP [XMPP-URI]. The resulting XMPP address MUST be encapsulated in XMPP
syntax as the value of the XMPP 'to' attribute. syntax as the value of the XMPP 'to' attribute.
2.2. Notify tag ":from" 2.2. Notify tag ":from"
The ":from" tag has no special meaning for this notification The ":from" tag has no special meaning for this notification
mechanism, and this specification puts no restriction on its use. As mechanism, and this specification puts no restriction on its use. As
noted, the value of the XMPP 'from' attribute specified in the XMPP noted, the value of the XMPP 'from' attribute specified in the XMPP
notification message MUST be the XMPP address of the notification notification message MUST be the XMPP address of the notification
service itself. The value of the ":from" tag MAY be transformed into service associated with the SIEVE engine. The value of the ":from"
XMPP syntax; if so, it SHOULD be encapsulated as the value of an XMPP tag MAY be transformed into XMPP syntax; if so, it SHOULD be
[SHIM] header named "Reply-To". encapsulated as the value of an XMPP [SHIM] header named "Reply-To".
2.3. Notify tag ":options" 2.3. Notify tag ":options"
The ":options" tag has no special meaning for this notification The ":options" tag has no special meaning for this notification
mechanism. Any handling of this tag is the responsibility of an mechanism. Any handling of this tag is the responsibility of an
implementation. implementation.
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.
The value of the ":importance" tag MAY be transformed into XMPP The value of the ":importance" tag MAY be transformed into XMPP
syntax (in addition to or instead of including in the default syntax (in addition to or instead of including in the default
message); if so, it MUST be encapsulated as the value of an XMPP message); if so, it SHOULD be encapsulated as the value of an XMPP
[SHIM] header named "Urgency", and the XML character of that header [SHIM] header named "Urgency", where the XML character of that header
MUST be "high" if the value of the ":importance" tag is "1", "medium" is "high" if the value of the ":importance" tag is "1", "medium" if
if the value of the ":importance" tag is "2", or "low" if the value the value of the ":importance" tag is "2", and "low" if the value of
of the ":importance" tag is "3". the ":importance" tag is "3".
2.5. Notify tag ":message" 2.5. Notify tag ":message"
If included, the ":message" tag MUST be transformed into the XML If the ":message" tag is included, that string MUST be transformed
character data of an XMPP <body/> element. If not included, the rule into the XML character data of an XMPP <body/> element (where the
specified in [NOTIFY] SHOULD be followed, as shown in the examples string is generated according to the guidelines specified in Section
below. 3.6 of [NOTIFY]). If the ":message" tag is not included, the rule
specified in [NOTIFY] SHOULD be followed.
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 XMPP <mailto:juliet@example.org>, the entity to be notified has an XMPP
address of romeo@example.com (resulting in an XMPP URI of address of romeo@example.com (resulting in an XMPP URI of
<xmpp:romeo@example.com>), and the notification service has an XMPP <xmpp:romeo@example.com>), and the notification service associated
address of notify.example.com (resulting in an XMPP URI of <xmpp: with the SIEVE engine has an XMPP address of notify.example.com
notify.example.com>). (resulting in an XMPP URI of <xmpp:notify.example.com>).
The following is a basic Sieve notify action with only a method: The following is a basic Sieve notify action with only a method:
notify "xmpp:romeo@example.com" notify "xmpp:romeo@example.com"
The resulting XMPP <message/> stanza might be as follows: The resulting XMPP <message/> stanza might be as follows:
<message from='notify.example.com' <message from='notify.example.com'
to='romeo@example.com' to='romeo@example.com'
xml:lang='en'> xml:lang='en'>
<subject>A Sieve instant notification!</subject> <subject>Sieve notification</subject>
<body>&lt;juliet@example.org&gt; Wherefore art thou?</body> <body>&lt;juliet@example.com&gt; You have new mail.</body>
</message> </message>
The following is a more advanced Sieve notify action with a method, The following is a more advanced Sieve notify action with a method,
importance, subject, and message, as well as a URL pointing to the importance, subject, and message, as well as a URL pointing to the
message: message:
notify :importance "1" notify :importance "1"
:message "Contact Juliet immediately!" :message "Contact Juliet immediately!"
"xmpp:romeo@example.com?message;subject=SIEVE" "xmpp:romeo@example.com?message;subject=SIEVE"
The resulting XMPP <message/> stanza might be as follows: The resulting XMPP <message/> stanza might be as follows:
<message from='notify.example.com' <message from='notify.example.com'
to='romeo@example.com' to='romeo@example.com'
xml:lang='en'> xml:lang='en'>
<subject>SIEVE</subject> <subject>Sieve notification</subject>
<body>Contact Juliet immediately!</body> <body>Contact Juliet immediately!</body>
<headers xmlns='http://jabber.org/protocol/shim'> <headers xmlns='http://jabber.org/protocol/shim'>
<header name='Urgency'>high</header> <header name='Urgency'>high</header>
</headers> </headers>
<x xmlns='jabber:x:oob'> <x xmlns='jabber:x:oob'>
<url> <url>
imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20
</url> </url>
</x> </x>
</message> </message>
skipping to change at page 6, line 19 skipping to change at page 6, line 39
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 ":from", 2. An implementation MAY ignore parameters specified in the ":from",
":importance", and ":options" tags. ":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 xmpp notification service. The value of the Sieve ":from" of the xmpp notification service associated with the SIEVE
tag MAY be transformed into the value of an XMPP [SHIM] header engine. The value of the Sieve ":from" tag MAY be transformed
named "Reply-To". into the value of an XMPP [SHIM] header named "Reply-To".
6. An implementation MUST NOT include any other extraneous 6. 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.
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
type (see [QUERIES]) and the associated "body" and "subject" type (see [QUERIES]) and the associated "body" and "subject"
parameters, which parameters SHOULD be mapped to the XMPP <body/> parameters, which parameters SHOULD be mapped to the XMPP <body/>
and <subject/> child elements of the XMPP <message/> stanza type, and <subject/> child elements of the XMPP <message/> stanza type,
respectively. However, if included then the Sieve notify respectively. However, if included then the Sieve notify
skipping to change at page 8, line 15 skipping to change at page 8, line 36
[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.
[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, August 2005. Internet Metadata", XSF XEP 0131, August 2005.
[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-12 (work in progress), Language", draft-ietf-sieve-3028bis-13 (work in progress),
February 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.
[XMPP-URI] [XMPP-URI]
Saint-Andre, P., "Internationalized Resource Identifiers Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the (IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)", Extensible Messaging and Presence Protocol (XMPP)",
draft-saintandre-rfc4622bis-01 (work in progress), draft-saintandre-rfc4622bis-01 (work in progress),
June 2007. June 2007.
8.2. Informative References 8.2. Informative References
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[IMAP-URL]
Newman, C. and A. Melnikov, "IMAP URL Scheme",
draft-ietf-lemonade-rfc2192bis-09 (work in progress),
August 2007.
[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-
Wesley, 2000. ISBN 0-201-61633-5), as amended by the Wesley, 2000. ISBN 0-201-61633-5), as amended by the
Unicode Standard Annex #27: Unicode 3.1 Unicode Standard Annex #27: Unicode 3.1
 End of changes. 19 change blocks. 
37 lines changed or deleted 60 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/