Sieve Working Group A. Melnikov
Internet-Draft Isode Limited
Intended status: Standards Track H. Schulzrinne
Expires: January 9, 2012 Columbia U.
Q. Sun
B. Leiba
K. Li
Huawei Technologies
July 8, 2011
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 9, 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
Melnikov, et al. Expires January 9, 2012 [Page 1]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Notify parameter "method" . . . . . . . . . . . . . . . . 3
2.1.1. Notify parameter "method" RAI review notes . . . . . . . . 4
2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . 6
2.3. Notify tag ":options" . . . . . . . . . . . . . . . . . . 7
2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . 7
2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . 7
2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . 8
2.7. Test notify_method_capability . . . . . . . . . . . . . . 8
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Requirements Conformance Checklist . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12
Melnikov, et al. Expires January 9, 2012 [Page 2]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
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].
[[REVIEW NOTES: Notes are placed below to document Adam Roach's RAI
review of the -00 version (
http://www.ietf.org/mail-archive/web/rai/current/msg00345.html ) and
Ben Campbell's review of the -02 version (
http://www.ietf.org/mail-archive/web/rai/current/msg00925.html )]]
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].
[[BEN'S REVIEW, MINOR 1; ** resolved **: I think you've got the right
idea here, but the terminology is wrong--I.e. the SIP URI _is_ the
SIP address. I think what you are after is something more along the
Melnikov, et al. Expires January 9, 2012 [Page 3]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
lines of forming a SIP Request based on an "external" URI, similarly
to what you might do with a URI in a hypertext link or on a business
card. I suggest merely saying something along the lines of "form a
SIP request according to the rules in rfc 3261"]]
2.1.1. Notify parameter "method" RAI review notes
[[RAI REVIEW NOTES: This section and its subsections are included for
editing purposes, and will be removed before the document is final,
when the issues are resolved.]]
2.1.1.1. RAI review notes from Adam Roach
[[ADAM'S REVIEW 1: These are the notes on section 2.1 from Adam
Roach's review of 9 Jan 2009.]]
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
[[BEN'S REVIEW, MAJOR 1a: These are the notes on section 2.1 from Ben
Campbell's review of 1 Sep 2010.]]
Melnikov, et al. Expires January 9, 2012 [Page 4]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
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
[[EDITOR NOTES TO RAI REVIEWS: These are the editor's responses, to
note work that still needs to be done.]]
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
Melnikov, et al. Expires January 9, 2012 [Page 5]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
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.
[[ADAM'S REVIEW 2; ** resolved **: My second area of concern is with
the handling of the "From" header field. The draft-ietf-sieve-notify
document clearly intends the ":from" value to indicate the value that
is typically rendered to the contacted party as the source of the
message. This intended behavior is upheld by the language in section
2.3 of draft-ietf-sieve-notify-mailto-10 (it places this value in the
SMTP "From:" header, and even suggests using the value in the "RCPT
FROM" command -- despite the easy availability of an SMTP "Reply-To:"
header). This mismatch in semantics between the protocols causes me
concern, as it may surprise users to have radically different
treatment of the value in the ":from" tag among protocols. Given the
text in the base sieve-notify document, I believe that the behavior
in sieve-notify-mailto is correct, and that the behavior in sieve-
notify-sip should be modified to align with it. (Indication of the
sending server can be made via other means, such as the SIP Call-
Info: header field).]]
[[BEN'S REVIEW, MAJOR 2a; ** resolved **: You need to consider how
the SIEVE implementation deals with SIP authentication, digest
challenges, etc. For example, if the peer SIP device responds with a
401 or 407 containing a digest-challenge, what credentials should be
Melnikov, et al. Expires January 9, 2012 [Page 6]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
used to respond to the challenge? Would you suggest the credentials
of a particular user? If so, are their security considerations
around having the SIEVE implementation know the credentials of a
particular user? Or should the SIEVE implementation authenticate
with server-wide credentials?]]
[[BEN'S REVIEW, MAJOR 2b; ** resolved **: Do you allow TLS mutual
authentication? If so, what client certificate should be
presented?]]
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".
[[BEN'S REVIEW, MINOR 2; ** resolved **: Do you expect the
:importance tag to set the importance of the SIP MESSAGE request, or
to convey the importance of the email that generated the notification
in the first place? If the first, then you're doing it right. If
the second, it might be more reasonable to put something in the
body.]]
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].
Melnikov, et al. Expires January 9, 2012 [Page 7]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
[[BEN'S REVIEW, MINOR 3; ** resolved **: This section needs to
mention the SIP MESSAGE request size limits from RFC 3428. Is the
body still expected to have a content-type of text/plain if no
:message tag is present?]]
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).
[[BEN'S REVIEW, MAJOR 3; ** resolved **: I'm not sure what you have
in mind here. If you are talking about request retransmission as
described in 3261, those are not suggestions--they are mandatory
parts of the SIP state machine. If you mean something like "try
again later because the destination party is offline" SIP doesn't
have much to say about that except in a few specific response
scenarios.]]
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.
[[BEN'S REVIEW, MINOR 4; ** resolved **: How could you ever know
this, short of trying the message? The implementation would have to
be presence aware to ever return something other than "maybe", and
even then it can't be certain.]]
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>.
Melnikov, et al. Expires January 9, 2012 [Page 8]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
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!
Melnikov, et al. Expires January 9, 2012 [Page 9]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
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].
[[BEN'S REVIEW, MINOR 5; ** resolved **: There are length limits
for SIP MESSAGE requests that this draft should consider. They
are large enough to be generally non constraining for this
usage, but they exist.]]
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.
Melnikov, et al. Expires January 9, 2012 [Page 10]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
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.
Melnikov, et al. Expires January 9, 2012 [Page 11]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
8. 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.
[RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
"Sieve Email Filtering: Extension for Notifications",
RFC 5435, 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/
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
Melnikov, et al. Expires January 9, 2012 [Page 12]
Internet-Draft Sieve Notification: SIP MESSAGE July 2011
Qian Sun
Huawei Technologies
Bantian, Longgang
Shenzhen, Guandong 518129
P.R China
Phone: +86 755 28780808
Email: sunqian@huawei.com
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. Expires January 9, 2012 [Page 13]
