summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6468.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6468.txt')
-rw-r--r--doc/rfc/rfc6468.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc6468.txt b/doc/rfc/rfc6468.txt
new file mode 100644
index 0000000..9a8508c
--- /dev/null
+++ b/doc/rfc/rfc6468.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Melnikov
+Request for Comments: 6468 Isode Limited
+Category: Standards Track B. Leiba
+ISSN: 2070-1721 K. Li
+ Huawei Technologies
+ February 2012
+
+
+ Sieve Notification Mechanism: SIP MESSAGE
+
+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 is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6468.
+
+Copyright Notice
+
+ Copyright (c) 2012 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.
+
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 1]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Notify Parameter "method" . . . . . . . . . . . . . . . . 3
+ 2.2. Notify Tag ":from" . . . . . . . . . . . . . . . . . . . . 3
+ 2.3. Notify Tag ":options" . . . . . . . . . . . . . . . . . . 4
+ 2.4. Notify Tag ":importance" . . . . . . . . . . . . . . . . . 4
+ 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . 4
+ 2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . 5
+ 2.7. Test notify_method_capability . . . . . . . . . . . . . . 5
+ 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Requirements Conformance Checklist . . . . . . . . . . . . . . 7
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
+
+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. (See RFC 5435 for
+ details about the motivation and use cases.) This document defines
+ how Session Initiation Protocol (SIP) URIs [RFC3261] are used to
+ generate notifications via SIP MESSAGE [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].
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 2]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+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 MUST include the URI parameter "method", with the value
+ "MESSAGE". Example:
+
+ notify "sip:romeo@example.com;method=MESSAGE"
+ --------------
+
+ Note that future specifications might extend this document and define
+ Sieve notifications that use SIP methods other than "MESSAGE".
+
+ The processing application MUST form a request according to the rules
+ specified in RFC 3261 [RFC3261].
+
+ Note that other URI schemes can also trigger SIP processing, but only
+ SIP and SIPS are defined here. Future extensions might define other
+ Sieve notification methods that use SIP through other URI schemes.
+
+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.
+
+
+
+
+Melnikov, et al. Standards Track [Page 3]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+ 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).
+ Note that because the Sieve ":importance" tag only has three values,
+ not all SIP "Priority" values can be represented in the
+ transformation. If this transformation 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". There is no mapping to the SIP value "emergency", nor to any
+ additional values that might be defined.
+
+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 values of the "From"
+ and "Subject" header fields of the triggering email message are
+ particularly useful to users receiving notifications, and including
+ them in the default message is generally a good idea, as shown in
+ Section 3.2 below. (However, see the Security Considerations,
+ Section 5.) The default body might also include the value of the
+ ":importance" tag, if one is specified.
+
+ Note that in no case is the actual triggering message body included
+ in the notification.
+
+ Implementations MUST comply with the SIP MESSAGE size limits, as
+ discussed in Section 8 of RFC 3428 [RFC3428].
+
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 4]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+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). The URI "body" parameter can serve the same purpose as the
+ Sieve ":message" tag, providing the message body of the SIP MESSAGE
+ request. If both are present at the same time, the Sieve processing
+ MUST ignore the "body" parameter.
+
+ Using the ":message" tag has advantages over using the "body"
+ parameter. Because the ":message" tag is part of the "notify"
+ statement syntax, it can be easier to include it in a script, and to
+ do things such as variable substitutions [RFC5229] with it. It is
+ also easier to include non-ASCII characters in the ":message" tag
+ because such characters have to be encoded if they are within URI
+ parameters, but can be included directly in UTF-8 in Sieve tag
+ values.
+
+ The policy for retrying delivery of failed notifications is specified
+ in RFC 3261 [RFC3261], according to the SIP error code returned
+ during an attempt to deliver a SIP notification. 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
+
+ Absent use of SIP extensions such as [RFC3856], it is impossible to
+ tell in advance whether the notification recipient is online and able
+ to receive a SIP MESSAGE. Expect the notify_method_capability test
+ for "online" to frequently 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"
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 5]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+ 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!
+
+
+
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 6]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+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 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,
+ from a confidentiality point of view, comparable to forwarding mail
+ to the notification recipient. Care must be taken when automatically
+ forwarding information, such as the sender and the subject of a
+
+
+
+Melnikov, et al. Standards Track [Page 7]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+ message, to ensure that confidential information is not sent into an
+ insecure environment or over an insecure channel. Depending upon the
+ environment, this might entail using SIPS URIs, not sending
+ information about the subject and/or the sender, or applying
+ heuristics to the message to determine what may be sent.
+
+ As required by RFC 3428, user agents that support the SIP MESSAGE
+ request MUST implement end-to-end authentication, body integrity, and
+ body confidentiality mechanisms. At the time of this writing, there
+ is not widespread deployment of SIP end-to-end security, so there can
+ be cases where it is not possible to use it, even though it is
+ implemented on one end. It's important to note that such situations
+ are open to exposure of user credentials, message content, and other
+ private information via man-in-the-middle and other passive attacks.
+
+ 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 that could
+ generate another SIP MESSAGE notification, loop prevention through
+ rate detection and limiting might be necessary. An implementation
+ might detect too many notifications within a given time period, too
+ many triggered by a particular sender, too many with the same
+ subject, or the like, and shut off the affected notifications for a
+ period of time or until manual intervention turns them back on.
+
+ If SIP MESSAGE requests might be billed by the message, or the use of
+ them might deplete a user's quota of messages, notification by this
+ mechanism can present a situation where someone using a large number
+ of messages to generate a large number of notifications will cause a
+ significant expense to the recipient. Because there is no external
+ way an attacker can tell that this is the case, such an attack would
+ likely be a random or nuisance attack. Nevertheless, users might be
+ warned of potential costs when they set up SIP MESSAGE notifications.
+
+ 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
+ has been added to the list of Sieve notification mechanisms
+ maintained at <http://www.iana.org/assignments/sieve-notification>.
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 8]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+ 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: [RFC6468]
+ Person and email address to contact for further information:
+ See authors of [RFC6468]
+
+7. Acknowledgements
+
+ This document borrows some text from RFC 5437 [RFC5437].
+
+ Henning Schulzrinne (hgs@cs.columbia.edu) was a special contributor
+ to this document, with early work and reviews.
+
+ The authors would like to thank Adam Roach and Eric Burger for their
+ helpful comments. Ben Campbell did a very thorough RAI-team review,
+ as well as a follow-up review to make sure we resolved all of his
+ issues satisfactorily. This document was greatly improved by their
+ input.
+
+ Qian Sun contributed text to this document.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3261] 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.
+
+ [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
+ and D. Gurle, "Session Initiation Protocol (SIP) Extension
+ for Instant Messaging", RFC 3428, December 2002.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
+ Language", RFC 5228, January 2008.
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 9]
+
+RFC 6468 Sieve Notification: SIP MESSAGE February 2012
+
+
+ [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
+ "Sieve Email Filtering: Extension for Notifications",
+ RFC 5435, January 2009.
+
+8.2. Informative References
+
+ [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
+ Initiation Protocol (SIP)", RFC 3856, August 2004.
+
+ [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
+ RFC 5229, January 2008.
+
+ [RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification
+ Mechanism: Extensible Messaging and Presence Protocol
+ (XMPP)", RFC 5437, January 2009.
+
+Authors' Addresses
+
+ Alexey Melnikov
+ Isode Limited
+ 5 Castle Business Village
+ 36 Station Road
+ Hampton, Middlesex TW12 2BX
+ UK
+
+ EMail: Alexey.Melnikov@isode.com
+ URI: http://www.melnikov.ca/
+
+
+ Barry Leiba
+ Huawei Technologies
+
+ Phone: +1 646 827 0648
+ EMail: barryleiba@computer.org
+ URI: http://internetmessagingtechnology.org/
+
+
+ Kepeng Li
+ Huawei Technologies
+ Huawei Base, Bantian, Longgang District
+ Shenzhen, Guangdong 518129
+ P.R. China
+
+ Phone: +86-755-28974289
+ EMail: likepeng@huawei.com
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 10]
+