Sieve Notification Mechanism: SIP MESSAGE
draft-ietf-sieve-notify-sip-message-03

Abstract

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on January 09, 2012.

Copyright Notice

Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Overview
• 1.2. Terminology
• 2. Definition
• 2.1. Notify parameter "method"
• 2.1.1. Notify parameter "method" RAI review notes
• 2.1.1.1. RAI review notes from Adam Roach
• 2.1.1.2. RAI review notes from Ben Campbell
• 2.1.1.3. Editor responses to RAI reviews
• 2.2. Notify tag ":from"
• 2.3. Notify tag ":options"
• 2.4. Notify tag ":importance"
• 2.5. Notify tag ":message"
• 2.6. Other Definitions
• 2.7. Test notify_method_capability
• 3. Examples
• 3.1. Example 1
• 3.2. Example 2
• 4. Requirements Conformance Checklist
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• Authors' Addresses

1. Introduction

1.1. Overview

The Notify extension [RFC5435] to the Sieve mail filtering language [RFC5228] is a framework for providing notifications by employing URIs that specify the notification mechanism. This document defines how SIP URIs RFC 3261 [RFC3261] are used to generate notifications via SIP MESSAGE RFC 3428 [RFC3428].

1.2. Terminology

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 [RFC2119].

This document inherits terminology from the Sieve email filtering language [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 [RFC3261].

2. Definition

The SIP MESSAGE mechanism defined in this document results in the sending of a SIP MESSAGE request to notify a recipient about an email message.

2.1. Notify parameter "method"

The "method" parameter MUST be a URI that conforms to the SIP (or SIPS) URI scheme (as specified in RFC 3261 [RFC3261]) and that identifies a SIP (or SIPS) recipient of the notification. The URI MAY include the resource identifier portion of a SIP address and URI parameters. The URI parameter "method" MUST be included and MUST contain the value "MESSAGE". (Note that future specifications might extend this document and define Sieve notifications that use other SIP methods.) The processing application MUST form a request according to the rules specified in RFC 3261 [RFC3261].

2.1.1. Notify parameter "method" RAI review notes

2.1.1.1. RAI review notes from Adam Roach

My first area of concern is that, while this seems a reasonable way to perform this functionality in SIP, I don't think it's the only reasonable way to do it in SIP. Consequently, this document needs to take care not to preclude future SIP mechanisms for SIEVE notifications. For example, the conveyance of more semantic information in a PUBLISH message would be quite useful when there is a dynamically changing community of parties interested in receiving notifications. (The PUBLISH would be sent to an event agent, which could then receive SUBSCRIBE requests from interested parties). This may be applicable, for example, when monitoring shared resources, such as technical support email queues.

However, the draft makes an implicit assumption that any SIEVE notification method URI starting with "sip:" necessarily will make use of the mechanism it defines, and never any other. There is no means for disambiguating among multiple mechanisms. In fact, the draft seems to go out of its way to ruin an extensibility mechanism that it would have automatically inherited from SIP: "The URI parameter 'method' MUST be ignored, because only the MESSAGE method is allowed by this specification."

I would suggest that the draft be amended to either *require* a "method" URI parameter (with "MESSAGE" indicating the mechanism described in this document), or to include additional information in the ":options" tag that explicitly indicates the use of this document's mechanism.

2.1.1.2. RAI review notes from Ben Campbell

You limit the method parameter to SIP or SIPS URIs. I can imagine several reasons you might have done this, most likely to cut down on the number of URIs that could would indicate the SIEVE rule was for SIP. But there are other perfectly legitimate URI types for SIP MESSAGE requests. For example TEL URIs are fairly common. IM URIs are also legal for SIP MESSAGE, although you're not likely to see those in the wild--but that could change in the future. SIP may add new legal URI types in the future.

One way around this would be to have some other part of the notify "method" parameter identify the fact that a SIP MESSAGE request is intended, and then allow any URI type that is legal for SIP MESSAGE.

You also include the SIP URI method=parameter for the sake of extensibility. This would be an issue if you allowed other URI types, since the method parameter is not necessarily defined for all URI types. I'm also not sure this gives you the extensibility you want--you would not be able to do anything useful with "method=FOO" without some additional SIEVE spec on how to send SIP FOO requests. I think you would be better off leaving off the method URI parameter, and instead encode something in the :options parameter.

[Note: I assume you added the method parameter based on feedback from Adam from a while back. I note that he suggested using either the method parameter, or something in :options. I am not disagreeing with him--I'm just suggesting that the :options approach is the better choice.]

2.1.1.3. Editor responses to RAI reviews

Both of these reviews bring up the same issue: we painted ourselves into a corner when we designed the Sieve Notify framework [RFC5435] in the first place, by making the "method" parameter a URI, and having the URI be the only way to distinguish the notification method. That means that the Sieve engine needs to be able to take a URI and know how to process it, and it also means that there's no way to use the same URI for different notification methods, depending upon the situation.

One problem with that is that we can't use "mailto:joe@example.org" for any notification mechanism other than email, even if some other notification mechanism keys off of an email address, and that if we use a "tel:" URI for SIP, we can't use "tel:" URIs for anything else.

Another problem is that we have to know, in advance, all the URI schemas that apply to a given notification method.

I don't know how to resolve these issues within the Sieve Notify framework. (Barry)

2.2. Notify tag ":from"

The value of the ":from" tag MUST use the SIP "From" header field syntax; if the :from value is specified, has valid syntax, and is valid according to the implementation-specific security checks (see Section 3.3 of Sieve Notify [RFC5435]), then the notification SHOULD include the "From" SIP header field containing the value of the :from notify tag. If the specified value is not valid, then it is ignored.

All SIP authentication, including challenges and client certificates, SHOULD be done in the context of the Sieve engine -- the Sieve engine is the identity being authenticated. This avoids security issues associated with the Sieve engine's having access to the end user's SIP authentication credentials. The Sieve engine MAY use server-wide credentials (including applicable certificates) that are the same for all scripts. Alternatively, it MAY, for auditing purposes, use different sets of Sieve-engine credentials when operating on behalf of different users.

See section 22 of RFC 3261 [RFC3261] for more information about SIP authentication.

2.3. Notify tag ":options"

Handling of the ":options" tag is implementation specific. This document doesn't require presence of any option and doesn't define how options are processed.

2.4. Notify tag ":importance"

The ":importance" tag is intended to convey the importance of the SIP MESSAGE notification, not the importance of the email message that generated the notification. The value of the ":importance" tag MAY, therefore, be transformed into SIP "Priority" header field (in addition to or instead of including it in the body of the message). If this is done, the value of the "Priority" header field MUST be "urgent" if the value of the ":importance" tag is "1", "normal" if the value of the ":importance" tag is "2", and "non-urgent" if the value of the ":importance" tag is "3".

2.5. Notify tag ":message"

If the ":message" tag is included, it MUST be transformed into the message-body of a SIP MESSAGE, which MUST have Content-Type value of "text/plain" with CHARSET="UTF-8". If the ":message" tag is not included, a default message will be used. The default message body SHOULD contain the values of the "From" and "Subject" header fields of the triggering email message (and MAY include the value of the ":importance" tag, if one is specified), as shown in Section 3.2 below.

Implementations MUST comply with the SIP MESSAGE size limits, as discussed in section 8 of RFC 3428 [RFC3428].

2.6. Other Definitions

An implementation MUST ignore any URI parameter it does not understand (the URI MUST be processed as if the parameter were not present). Implementations SHOULD NOT use the hname "body" parameter value as the message-body of the SIP MESSAGE request. If the hname "body" parameter and ":message" tag are present at the same time, the "body" parameter MUST be ignored.

If the notification request fails, there will be a SIP error code describing the failure. The policy for retrying delivery of failed notifications is specified in RFC 3261 [RFC3261], according to the error code. In other words, unlike the situation with some other Sieve notification methods, retries for SIP MESSAGE notifications are controlled by the notification protocol itself (SIP).

2.7. Test notify_method_capability

Because it is impossible to tell in advance whether the notification recipient is online and able to receive a SIP MESSAGE, the notify_method_capability test for "online" will always return "maybe" for this notification method.

3. Examples

In the following examples, the sender of the email has an address of juliet@example.org, the entity to be notified has a SIP address of <sip:romeo@example.com>, and the notification service has a SIP address <sip:notifier@example.com>.

3.1. Example 1

The following is a basic Sieve notify action with only a method:

notify "sip:romeo@example.com;method=MESSAGE"

The resulting SIP MESSAGE request might be as follows:

   MESSAGE sip:romeo@example.com SIP/2.0
   Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse
   Max-Forwards: 70
   From: sip:notifier@example.com;tag=32328
   To: sip:romeo@example.com
   Call-ID: asd88asd77a@1.2.3.4
   CSeq: 1 MESSAGE
   Date: Sat, 13 Nov 2010 23:29:00 GMT
   Content-Type: text/plain
   Content-Length: 53   

   <juliet@example.com> wrote: Contact me immediately!

In the example above the email message was received from juliet@example.com and had "Subject: Contact me immediately!"

3.2. Example 2

The following is a more advanced Sieve notify action with a method, importance, subject, and message:

   notify :importance "1"
       :message "You got new mail!"
       "sip:romeo@example.com;method=MESSAGE?subject=SIEVE"

   MESSAGE sip:romeo@example.com SIP/2.0
   Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse
   Max-Forwards: 70
   From: sip:notifier@example.com;tag=32328
   To: sip:romeo@example.com
   Subject: SIEVE
   Priority: urgent
   Call-ID: asd88asd77a@1.2.3.4
   CSeq: 1 MESSAGE
   Date: Fri, 08 Apr 2011 06:54:00 GMT
   Content-Type: text/plain
   Content-Length: 19

   You got new mail!

4. Requirements Conformance Checklist

Section 3.8 of Sieve Notify [RFC5435] specifies a set of requirements for Sieve notification methods. A checklist is provided here to show conformance of the SIP MESSAGE notification method.

1. No new Sieve tags have been added to the "notify" action.
2. An implementation of the SIP MESSAGE notification method SHOULD NOT modify the final notification text, except to comply with SIP MESSAGE length limits. Deployments MAY make operational decisions about notification text, for reasons such as privacy and confidentiality. Modification of characters themselves should not be necessary, since the SIP MESSAGE body is encoded in UTF-8 [RFC3629].
   
   
3. An implementation MAY ignore parameters specified in the ":importance", and ":options" tags.
4. A default message is suggested in Section 2.5.
5. A notification sent via the SIP MESSAGE notification method MAY include the Date header field containing the date-time of the moment when the SIP MESSAGE notification was generated.
6. The notification source is identified through the SIP "From:" header field, via the Sieve Notify ":from" tag (see Section 2.2.
7. An implementation MUST NOT include any other extraneous information not specified in parameters to the notify action.
8. An implementation MUST ignore any URI parameters it does not understand (i.e., the URI MUST be processed as if the action or parameter were not present). See Section 2.6 for more details.
9. The notify_method_capability test for the "online" notification-capability behaves as described in Section 2.7.
10. The policy for retrying delivery of failed notifications is specified in RFC 3261 [RFC3261], as noted in Section 2.6.

5. Security Considerations

Depending on the information included, sending a notification can be comparable to forwarding mail to the notification recipient. Care must be taken when forwarding mail automatically, to ensure that confidential information is not sent into an insecure environment or over an insecure channel.

User agents that support the SIP MESSAGE request MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms.

The Sieve Notify extension specifies that notification methods MUST provide mechanisms for avoiding notification loops. In this case, the SIP protocol itself prevents loops, and no explicit work is needed within the notification mechanism. In situations where a SIP MESSAGE notification can result in an email message, which could generate another SIP MESSAGE notification, loop prevention through rate limiting might be necessary.

Other security considerations given in the Sieve base specification [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 [RFC3261] are also relevant to this document.

6. IANA Considerations

The following template provides the IANA registration of the Sieve notification mechanism specified in this document. This information should be added to the list of Sieve notification mechanisms maintained at <http://www.iana.org/assignments/sieve-notification>.

To: iana@iana.org
Subject: Registration of new Sieve notification mechanism
Mechanism name: sip-message
Mechanism URI: SIP/SIPS as specified in RFC 3261 [RFC3261]
Mechanism-specific options: none
Standards Track/IESG-approved experimental RFC number: [RFC XXXX]
Person and email address to contact for further information:
    See authors of [RFC XXXX]

7. Acknowledgements

This document borrows some text from draft-ietf-sieve-notify-xmpp.

The authors would like to specially thank Adam Roach and Eric Burger for their helpful comments.

8. References

Authors' Addresses