| TOC |
|
By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2008.
Copyright © The IETF Trust (2007).
This document describes using the existing SIP message-summary event package to carry notifications generated from Sieve filter rules.
1.
Conventions
2.
Background
3.
Use of Sieve filters in a message-summary subscription
4.
New MIME Type for notification bodies
5.
Example Message Flow
6.
Formal Syntax
7.
Security Considerations
8.
IANA Considerations
8.1.
MIME Registration for application/sieve-notification+xml
9.
Relax NG Schema
10.
References
10.1.
Normative References
10.2.
Informational References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [5].
| TOC |
Sieve (Showalter, T. and P. Guenther, “Sieve: An Email Filtering Language,” February 2007.) [1] is an email filtering language. Individual rules in this language check for specific conditions, and then execute specific actions. One supported action sends a Sieve notification (Melnikov, A., “Sieve Extension: Notifications,” February 2007.) [2], for example using email (Leiba, B. and M. Haardt, “Sieve Notification Mechanism: mailto,” March 2007.) [9] or XMPP (Saint-Andre, P. and A. Melnikov, “Sieve Notification Mechanism: xmpp,” March 2007.) [10] (Extensible Messaging and Presence Protocol).
SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [3] is a protocol used for rendezvous, management of multimedia sessions, and relevant event notifications (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [4]. Messaging Waiting Indication is a common feature of telephone networks. It typically involves an audible or visible indication that messages are waiting, such as playing a special dial tone, lighting a light or indicator on the phone, displaying icons or text, or some combination. RFC 3842 (Mahy, R., “A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP),” August 2004.) [7] defines a SIP event package to alert the subscriber when the types of messages available have changed.
Using SIP-Specific Event Notification, A Subscriber User Agent (typically an IP phone or SIP software User Agent) subscribes to the status of their messages. A SIP User Agent acting on behalf of the user's messaging system then notifies the Subscriber whenever the messaging account's messages have changed. (This Notifier could be composed with a User Agent that provides a real-time media interface to send or receive messages, or it could be a standalone entitiy.) The Notifier sends a message summary in the body of a NOTIFY, encoded in a new MIME type defined later in this document. A User Agent can also explicitly fetch the current status.
This document describes how to use the existing SIP message-summary event package to convey only notifications specified by the Sieve filtering language. Sieve notifications in the context of this event package are always explicitly authorized. This avoids delivering notifications about possibly unwanted unsolicited events.
The Email System Event Notification Model (Dusseault, L., “Email System Event Notification Model,” June 2007.) [12] describes sending notifications about several kinds of events which are relevant to email systems [11] (Gellens, R. and C. Newman, “Internet Message Store Events,” May 2007.), and describes a model to convey those notifications. This document is largely orthogonal in that it provides access to almost none of the mailbox events, and it explicitly defines a mechanism to dynamically setup a sieve filter and solicit notifications indirectly triggered by new incoming messages (which the model does not address). The notifier for this package could be collocated with the "Publisher Notifications Aggregator (PNA)" role described in the model document.
| TOC |
SIP event notification is designed to present consistent, reliable, synchronized state even when SIP user agents temporarily lose and re-establish network connectivity. Because of this design requirement, a new subscription always contains an explicit initial state. In the context of Sieve notifications, this initial state can contain notifications that the subscriber has not seen yet, even if those notifications where already sent using other notification methods or received by other SIP subscribers. Since multiple Sieve notifications could be received in a single NOTIFY request, the notifications are enclosed in a simple container using XML, as described in the next section.
To explicitly indicate the begining of time to use for notifications, the subscriber can include a new optional SIP Event header parameter 'notify-counter'. If this parameter is included, the notifier can provide notifications consistent with this "version" of the notify-counter. If the notification contains the same notify-counter as the corresponding subscription, the subscriber knows that it did not miss any notifications.
When a MIME body is included in a SIP SUBSCRIBE request, this body is treated as an event filter. In this application, the filter is an "application/sieve" document, with a few specific requirements described below.
The filter document used for filtering SHOULD NOT include Actions other than "notify", for example: keep, delete, or fileto. The Sieve notify tag ":method" MUST NOT be included, and MUST be ignored if it present. The notification method and URI are already specified more formally in the SIP SUBSCRIBE request. Likewise the notify tag ":from" MUST be ignored. The From header of the notification is already set in the SIP dialog used for the subscription.
The ":message" notify tag is used to construct a (probably human-readable) string that appears in the 'message' element of the notification. This document also defines a new notify option "headerlist" (used with the ":options" notify tag). The value of the "headerlist" option is a comma-separated list of email headers, each of which will be included in its own 'header' element in the notification. The usage of the headerlist is completely optional.
| TOC |
This section defines a new MIME type "application/sieve-notification+xml". This document format contains a top-level 'sieve-notifications' element, which has a mandatory 'notify-counter' attribute. This counter is an unsigned integer. This element contains zero or more 'notification' elements. Each 'notification' element contains exactly one 'message' element with the populated contents of the ":message" notify tag. Each 'notification' element can also contain zero or more 'header' elements. Each 'header' element has a mandatory 'name' attribute with the name of a header from the 'headerlist' ":options" notify tag. The contents of the 'header' element is the value of the named header.
A relax NG schema for this body type is included in the Appendix. Below is a Sieve filter in a SUBSCRIBE body, and the corresponding notification body. A full example is given in the next section.
=== SUBSCRIBE Body ===
require ["enotify"];
if header :contains "from" "example.com" {
notify :message "Reminder to call about project foobar"
:options "headerlist" "From,Subject";
}
=== NOTIFY Body ===
<?xml version="1.0"?>
<sieve-notifications notify-counter="4589">
<notification>
<header name="From">alice@example.com</header>
<header name="Subject">Foobar status report</header>
<message>Reminder to call about project foobar</message>
</notification>
</sieve-notifications>
| TOC |
The examples shown below are for informational purposes only.
In the example call flow below, Alice's IP phone subscribes to the status of Alice's messages. Via headers are omitted for clarity.
Subscriber Notifier
| |
| A1: SUBSCRIBE (new) |
|---------------------->|
| A2: 200 OK |
|<----------------------|
| |
| A3: NOTIFY (sync) |
|<----------------------|
| A4: 200 OK |
|---------------------->|
| |
| |<--- email arrives
| A5: NOTIFY (change) |
|<----------------------|
| A6: 200 OK |
|---------------------->|
| |
| |
| A7: (re)SUBSCRIBE |
|---------------------->|
| A8: 200 OK |
|<----------------------|
| |
| A9: NOTIFY (sync) |
|<----------------------|
| A10: 200 OK |
|---------------------->|
| |
| |
| A11: (un)SUBSCRIBE |
|---------------------->|
| A12: 200 OK |
|<----------------------|
| |
| A13: NOTIFY (sync) |
|<----------------------|
| A14: 200 OK |
|---------------------->|
A1: Subscriber (Alice's phone) ->
Notifier (Alice's voicemail gateway)
Subscribe to Alice's message summary status for 1 hour.
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
To: <sip:alice@example.com>
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 03:55:06 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 4 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Event: message-summary
Expires: 3600
Accept: application/sieve-notification+xml
Content-Type: application/sieve
Content-Length: 85
require ["enotify"];
if header :contains "from" "example.com" {
notify :message "Reminder to call about project foobar"
:options "headerlist" "From,Subject";
}
A2: Notifier -> Subscriber
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 03:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 4 SUBSCRIBE
Expires: 86400
Content-Length: 0
A3: Notifier -> Subscriber
(immediate synchronization of current state:
no notifications to report)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 03:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 20 NOTIFY
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Subscription-State: active;expires=3600
Content-Type: application/sieve-notification+xml
Content-Length: 79
<?xml version="1.0"?>
<sieve-notifications notify-counter="4588"/>
A4: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 03:55:08 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 20 NOTIFY
Content-Length: 0
A5: Notifier -> Subscriber
This is a notification of a new message.
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 04:28:53 GMT
Contact: <sip:alice@vmail.example.com>
Call-ID: 1349882@alice-phone.example.com
CSeq: 31 NOTIFY
Event: message-summary
Subscription-State: active;expires=1665
Content-Type: application/sieve-notification+xml
Content-Length:
<?xml version="1.0"?>
<sieve-notifications notify-counter="4589">
<notification>
<header name="From">alice@example.com</header>
<header name="Subject">Foobar status report</header>
<message>Reminder to call about project foobar</message>
</notification>
</sieve-notifications>
A6: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 04:28:53 GMT
Call-ID: 1349882@alice-phone.example.com
CSeq: 31 NOTIFY
Content-Length: 0
A7: Subscriber -> Notifier
Refresh subscription.
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 04:55:06 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 8 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Event: message-summary;notify-counter=4589
Expires: 3600
Accept: application/sieve-notification+xml
Content-Length: 0
A8: Notifier -> Subscriber
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 04:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 8 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Expires: 86400
Content-Length: 0
A9: Notifier -> Subscriber
(immediate synchronization of current state)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 04:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 47 NOTIFY
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Subscription-State: active;expires=3600
Content-Type: application/sieve-notification+xml
Content-Length: 79
<?xml version="1.0"?>
<sieve-notifications notify-counter="4589"/>
A10: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 04:55:08 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 47 NOTIFY
Contact: <sip:alice@vmail.example.com>
A11: Subscriber -> Notifier
Un-subscribe after "alice" logs out.
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 05:35:06 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 17 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Event: message-summary
Expires: 0
Content-Length: 0
A12: Notifier -> Subscriber
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 05:35:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 17 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Content-Length: 0
A13: Notifier -> Subscriber
(immediate synchronization of current state,
which the subscriber can now ignore)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 05:35:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 56 NOTIFY
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Subscription-State: terminated;reason=timeout
Content-Type: application/sieve-notification+xml
Content-Length: 79
<?xml version="1.0"?>
<sieve-notifications notify-counter="4589"/>
A14: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 05:35:08 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 56 NOTIFY
Event: message-summary
Content-Length: 0
| TOC |
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.) [6]. This document defines a new Event header parameter with the name 'notify-counter'. Its formal syntax is described below:
notify-counter = "notify-counter" EQUAL 1*DIGIT
; MUST NOT exceed 2^32-1
| TOC |
The bulk of the relevant privacy and security considerations are discussed in Sieve (Showalter, T. and P. Guenther, “Sieve: An Email Filtering Language,” February 2007.) [1] and Sieve notifications (Melnikov, A., “Sieve Extension: Notifications,” February 2007.) [2]. In addition, SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [3] subscriptions SHOULD be authenticated and authorized to fetch notifications for the target SIP resource / mailbox. (Digest authentication is mandatory to implement in all SIP nodes.) In addition, the SIP Identity header (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [8] can be used to insure that notifications were not forged and were not modified in transit. To prevent eavesdropping, the SIP subscriber could insist on using the sips: scheme which insures that SIP messages are only sent over TLS protected channels. Finally, a truly paranoid user can use the SIP S/MIME mechanism for end-to-end encryption, authentication, and message integrity.
| TOC |
| TOC |
MIME media type name: application
MIME subtype name: sieve-notification+xml
Required parameters: none.
Optional parameters: none.
Encoding considerations: Usual XML stuff here.
Security considerations: See the "Security Considerations"
section in this document.
Interoperability considerations: none
Published specification: This document.
Applications which use this media: The sieve-notification application subtype supports the exchange of sieve email notification information in SIP networks.
Additional information:
1. Magic number(s): N/A
2. File extension(s): N/A
3. Macintosh file type code: N/A
| TOC |
<element name="sieve-notification">
<zeroOrMore>
<element name="notification">
<zeroOrMore>
<element name="header">
<attribute name="name">
<text/>
</attribute>
</element>
</zeroOrMore>
<element name="message"/>
</element>
</zeroOrMore>
<attribute name="notify-count">
<data type="integer"/>
</attribute>
</element>
| TOC |
| TOC |
| [1] | Showalter, T. and P. Guenther, “Sieve: An Email Filtering Language,” draft-ietf-sieve-3028bis-12 (work in progress), February 2007. |
| [2] | Melnikov, A., “Sieve Extension: Notifications,” draft-ietf-sieve-notify-07 (work in progress), February 2007. |
| [3] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002. |
| [4] | Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, June 2002. |
| [5] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [6] | Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 4234, October 2005 (TXT, HTML, XML). |
| [7] | Mahy, R., “A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP),” RFC 3842, August 2004. |
| [8] | Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” RFC 4474, August 2006. |
| TOC |
| [9] | Leiba, B. and M. Haardt, “Sieve Notification Mechanism: mailto,” draft-ietf-sieve-notify-mailto-02 (work in progress), March 2007. |
| [10] | Saint-Andre, P. and A. Melnikov, “Sieve Notification Mechanism: xmpp,” draft-ietf-sieve-notify-xmpp-04 (work in progress), March 2007. |
| [11] | Gellens, R. and C. Newman, “Internet Message Store Events,” draft-ietf-lemonade-msgevent-02 (work in progress), May 2007. |
| [12] | Dusseault, L., “Email System Event Notification Model,” draft-dusseault-email-notif-model-00 (work in progress), June 2007. |
| TOC |
| Rohan Mahy | |
| Plantronics | |
| 345 Encinal St | |
| Santa Cruz, CA 95060 | |
| USA | |
| Email: | rohan@ekabal.com |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).