Network Working Group A. Melnikov
Internet-Draft Isode Limited
Intended status: Standards Track H. Schulzrinne
Expires: January 4, 2011 Columbia U.
Q. Sun
Huawei Technologies
July 3, 2010
Sieve Notification Mechanism: SIP MESSAGE
draft-ietf-sieve-notify-sip-message-02
Abstract
This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent over the 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 4, 2011.
Copyright Notice
Copyright (c) 2010 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
Melnikov, et al. Expires January 4, 2011 [Page 1]
Internet-Draft Sieve Notification: SIP MESSAGE July 2010
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Notify parameter "method" . . . . . . . . . . . . . . . . . . 3
3.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 3
3.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . . . 4
3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4
3.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . . 4
3.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . . 4
3.7. Test notify_method_capability . . . . . . . . . . . . . . . . 5
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements Conformance . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
Melnikov, et al. Expires January 4, 2011 [Page 2]
Internet-Draft Sieve Notification: SIP MESSAGE July 2010
1. Conventions Used in this Document
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].
2. Introduction
2.1. Overview
The NOTIFY [NOTIFY] extension to the SIEVE [SIEVE] mail filtering
language is a framework for providing notifications by employing URIs
to specify the notification mechanism. This document defines how SIP
URIs (see RFC 3261 [SIP]) are used to generate notifications via the
SIP MESSAGE (see RFC 3428 [RFC3428]).
2.2. Terminology
This document inherits terminology from NOTIFY [NOTIFY], SIEVE
[SIEVE], and RFC 3261 [SIP].
3. 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.
3.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 [SIP]) 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 extract a SIP address from the URI in
accordance with the processing rules specified in RFC 3261 [SIP].
The resulting SIP address MUST be encapsulated in SIP URI syntax as
Request-URI and the value of the "To" header field of the SIP MESSAGE
request.
3.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
Melnikov, et al. Expires January 4, 2011 [Page 3]
Internet-Draft Sieve Notification: SIP MESSAGE July 2010
valid according to the implementation-specific security checks (see
Section 3.3 of [NOTIFY]), 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.
3.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.
3.4. Notify tag ":importance"
The value of the ":importance" tag MAY be transformed into SIP
"Priority" header field (in addition to or instead of including in
the default message); if specified, 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", or
"non-urgent" if the value of the ":importance" tag is "3".
3.5. Notify tag ":message"
If included, the ":message" tag MUST be transformed into the message-
body of a SIP MESSAGE, which MUST have Content-Type value of "text/
plain" with CHARSET="UTF-8". [[anchor10: Should application/
sieve-notification+xml Content type from draft-mahy-sieve-notify-sip
be used instead?]] If not included, the default message body SHOULD
contain 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 one of the
examples below.
3.6. Other Definitions
The value of the SIP "From" header field specified in the SIP
notification message MUST be the SIP address of the notification
service itself.
An implementation MUST ignore any URI parameter it does not
understand (i.e., the URI MUST be processed as if the parameter were
not present). It is RECOMMENDED not to use the hname "body"
parameter value as the message-body of the SIP MESSAGE request. If
hname "body" parameter and ":message" tag are present at the same
time, the "body" parameter MUST be ignored.[[anchor11: Any other SIP
URI parameters that should be used?]]
The policy of retry delivery of a notification is a matter of
implementation and is not specified herein. But it SHOULD follow the
Melnikov, et al. Expires January 4, 2011 [Page 4]
Internet-Draft Sieve Notification: SIP MESSAGE July 2010
suggestion for retry in RFC 3261 [SIP].[[anchor12: Is this correct?
When one would possibly want to violate suggestions from RFC 3261?
If this is not correct, then the paragraph should read instead: The
policy of retry delivery of a notification is specified in
[RFC3261].]]
3.7. Test notify_method_capability
The notify_method_capability test for "online" may return "yes" or
"no" only if the Sieve processor can determine with certainty whether
or not the recipient of the notification message is can receive the
notification immediately. Otherwise, the test returns "maybe" for
this notification method. [[anchor13: Add some specific details
regarding determining online status of the recipient.]]
4. 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>.
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
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!"
The following is a more advanced Sieve notify action with a method,
importance, subject, and message:
Melnikov, et al. Expires January 4, 2011 [Page 5]
Internet-Draft Sieve Notification: SIP MESSAGE July 2010
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
Content-Type: text/plain
Content-Length: 19
You got new mail!
5. Requirements Conformance
Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve
notification methods. The conformance of the SIP MESSAGE
notification mechanism is provided here.[[anchor16: Need to compare
this section with XMPP NOTIFY (RFC 5437) and Email NOTIFY (RFC
5436).]]
1. An implementation of the SIP MESSAGE notification method SHOULD
NOT modify the final notification text (e.g., to limit the
length); however, a given deployment MAY do so. Modification of
characters themselves should not be necessary, since SIP MESSAGE
body is encoded in UTF-8 [RFC3629].
2. An implementation MAY ignore parameters specified in the
":importance", and ":options" tags.
3. If not included, the default message body SHOULD contain 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 one of the examples below.
4. A notification sent via the SIP MESSAGE notification method
SHOULD include the Date header field containing the date-time of
the moment when the SIP MESSAGE notification was generated.
5. The value of the Sieve ":from" tag SHOULD be transformed into the
value of an SIP "From" header field, if it has valid syntax and
is valid according to the implementation-specific security checks
(see Section 3.3 of [NOTIFY]. If ":from" is not specified or is
not valid, the SIP "From:" header field of the notification
message SHOULD be set to the SIP address of the notification
service associated with the SIEVE engine.
Melnikov, et al. Expires January 4, 2011 [Page 6]
Internet-Draft Sieve Notification: SIP MESSAGE July 2010
6. The value of the SIP "To" header field MUST be the SIP address
specified in the SIP URI contained in the Sieve notify "method"
parameter.
7. 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 3.6 for more details.
8. An implementation MUST NOT include any other extraneous
information not specified in parameters to the notify action.
9. The notify_method_capability test for the "online" notification-
capability behaves as described in Section 3.7.
6. Security Considerations
[[anchor17: TBD]]
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.
UAs that support the MESSAGE request MUST implement end-to-end
authentication, body integrity, and body confidentiality mechanisms.
Other security considerations given in [NOTIFY], [SIEVE] and [SIP]
are also relevant to this document.
7. IANA Considerations
The following template provides the IANA registration of the Sieve
notification mechanism specified in this document:
To: iana@iana.org
Subject: Registration of new Sieve notification mechanism
Mechanism name: sip-message
Mechanism URI: SIP/SIPS as specified in RFC 3261 [SIP]
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]
This information should be added to the list of Sieve notification
mechanisms maintained at
<http://www.iana.org/assignments/sieve-notification>.
Melnikov, et al. Expires January 4, 2011 [Page 7]
Internet-Draft Sieve Notification: SIP MESSAGE July 2010
8. 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.
9. Normative References
[NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
Martin, "Sieve Extension: Notifications", RFC 5435,
January 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[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.
[SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, January 2008.
[SIP] 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.
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/
Melnikov, et al. Expires January 4, 2011 [Page 8]
Internet-Draft Sieve Notification: SIP MESSAGE July 2010
Henning Schulzrinne
Columbia U.
Columbia University Department of Computer Science
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
Qian Sun
Huawei Technologies
Bantian Longgang
Shenzhen, Guandong 518129
P.R China
Phone: +86 755 28780808
Email: sunqian@huawei.com
Melnikov, et al. Expires January 4, 2011 [Page 9]
