One document matched: draft-ietf-sieve-notify-sip-message-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC5228 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5228.xml'>
<!ENTITY RFC5435 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5435.xml'>
<!ENTITY RFC3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC3428 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3428.xml'>
<!ENTITY RFC3629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
<!ENTITY RFC3856 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml'>
<!ENTITY RFC5437 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5437.xml'>
]>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc tocindent="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="std"
docName="draft-ietf-sieve-notify-sip-message-06"
ipr="trust200902"
xml:lang="en">
<front>
<title abbrev="Sieve Notification: SIP MESSAGE">Sieve Notification Mechanism: SIP MESSAGE</title>
<author initials='A.' surname="Melnikov" fullname='Alexey Melnikov'>
<organization>Isode Limited</organization>
<address>
<postal>
<street>5 Castle Business Village</street>
<street>36 Station Road</street>
<city>Hampton</city>
<region>Middlesex</region>
<code>TW12 2BX</code>
<country>UK</country>
</postal>
<email>Alexey.Melnikov@isode.com</email>
<uri>http://www.melnikov.ca/</uri>
</address>
</author>
<author initials="Q." surname="Sun" fullname="Qian Sun">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang</street>
<city>Shenzhen</city>
<region>Guandong</region>
<code>518129</code>
<country>P.R China</country>
</postal>
<phone>+86 755 28780808</phone>
<email>sunqian@huawei.com</email>
</address>
</author>
<author initials='B.' surname="Leiba" fullname='Barry Leiba'>
<organization>Huawei Technologies</organization>
<address>
<phone>+1 646 827 0648</phone>
<email>barryleiba@computer.org</email>
<uri>http://internetmessagingtechnology.org/</uri>
</address>
</author>
<author initials="K." surname="Li" fullname="Kepeng Li">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<phone>+86-755-28974289</phone>
<email>likepeng@huawei.com</email>
</address>
</author>
<date year="2011" />
<area>Applications</area>
<workgroup>Sieve Working Group</workgroup>
<keyword>Sieve</keyword>
<keyword>SIP</keyword>
<keyword>notification</keyword>
<abstract>
<t>This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent over SIP MESSAGE.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<section title="Overview">
<t>
The <xref target="RFC5435">Notify extension</xref> to the
<xref target="RFC5228">Sieve mail filtering language</xref>
is a framework for providing notifications by employing URIs that specify
the notification mechanism.
This document defines how Session Initiation Protocol
(SIP) URIs <xref target="RFC3261">RFC 3261</xref>
are used to generate notifications via
SIP MESSAGE <xref target="RFC3428">RFC 3428</xref>.
</t>
</section>
<section title="Terminology">
<t>
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
<xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
This document inherits terminology from the
<xref target="RFC5228">Sieve email filtering language</xref>, the
<xref target="RFC5435">Sieve Notify extension</xref>, and
<xref target="RFC3261">RFC 3261</xref>.
</t>
</section>
</section>
<section title="Definition">
<t>
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.
</t>
<section title='Notify parameter "method"'>
<t>
The "method" parameter MUST be a URI that conforms to the SIP
or SIPS URI scheme (as specified in <xref target="RFC3261">RFC 3261</xref>)
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 <xref target="RFC3261">RFC 3261</xref>.
</t>
<t>
Note that other URI schemes can also trigger SIP processing, but only SIP
and SIPS are defined here. Future extensions might define other notification
methods using SIP, using other URI schemes.
</t>
</section>
<section anchor="from-tag" title='Notify tag ":from"'>
<t>
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 <xref target="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.
</t>
<t>
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.
</t>
<t>
See section 22 of RFC 3261 <xref target="RFC3261"/> for more information
about SIP authentication.
</t>
</section>
<section title='Notify tag ":options"'>
<t>
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.
</t>
</section>
<section title='Notify tag ":importance"'>
<t>
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.
</t>
</section>
<section anchor="message-tag" title='Notify tag ":message"'>
<t>
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 <xref target="Example2"/> below.
</t>
<t>
Note that in no case is the actual triggering message body included in the
notification.
</t>
<t>
Implementations MUST comply with the SIP MESSAGE size limits, as discussed in
section 8 of RFC 3428 <xref target="RFC3428"/>.
</t>
</section>
<section anchor="other-req" title="Other Definitions">
<t>
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.
</t>
<t>
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 <xref target="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).
</t>
</section>
<section anchor="notify_method_capability" title="Test notify_method_capability">
<t>
Because, absent use of SIP extensions such as <xref target="RFC3856"/>,
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.
</t>
</section>
</section>
<section title="Examples">
<t>
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>.
</t>
<section anchor="Example1" title="Example 1">
<t>
The following is a basic Sieve notify action with only a method:
</t>
<t>
notify "sip:romeo@example.com;method=MESSAGE"
</t>
<t>
The resulting SIP MESSAGE request might be as follows:
</t>
<figure>
<artwork><![CDATA[
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!
]]></artwork>
<postamble>
In the example above the email message was received from
juliet@example.com and had "Subject: Contact me immediately!"
</postamble>
</figure>
</section>
<section anchor="Example2" title="Example 2">
<t>
The following is a more advanced Sieve notify action with a method,
importance, subject, and message:
</t>
<figure>
<artwork><![CDATA[
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!
]]></artwork>
</figure>
</section>
</section>
<section title="Requirements Conformance Checklist" toc="default">
<?rfc subcompact="no"?>
<t>
Section 3.8 of Sieve Notify <xref target="RFC5435"/> specifies
a set of requirements for Sieve notification methods.
A checklist is provided here to show
conformance of the SIP MESSAGE notification method.
<list style="numbers">
<t>
No new Sieve tags have been added to the "notify" action.
</t>
<t>
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 <xref target="RFC3629"/>.
</t>
<t>
An implementation MAY ignore parameters specified in the
":importance", and ":options" tags.
</t>
<t>
A default message is suggested in <xref target="message-tag"/>.
</t>
<t>
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.
</t>
<t>
The notification source is identified through the SIP "From:" header field,
via the Sieve Notify ":from" tag (see <xref target="from-tag"/>.
</t>
<t>
An implementation MUST NOT include any other extraneous
information not specified in parameters to the notify action.
</t>
<t>
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 <xref target="other-req"/>
for more details.
</t>
<t>
The notify_method_capability test for the "online" notification-capability
behaves as described in <xref target="notify_method_capability"/>.
</t>
<t>
The policy for retrying delivery of failed notifications is specified in
RFC 3261 <xref target="RFC3261"/>, as noted in <xref target="other-req"/>.
</t>
</list>
</t>
<?rfc subcompact="yes"?>
</section>
<section anchor="security" title="Security Considerations" toc="default">
<t>
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 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.
</t>
<t>
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. Its 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.
</t>
<t>
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
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.
</t>
<t>
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.
</t>
<t>
Other security considerations given in
the Sieve base specification <xref target="RFC5228"/>,
the Sieve Notify extension <xref target="RFC5435"/>, and
RFC 3261 <xref target="RFC3261"/>
are also relevant to this document.
</t>
</section>
<section title="IANA Considerations">
<t>
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>.
</t>
<t>
To: iana@iana.org<vspace/>
Subject: Registration of new Sieve notification mechanism<vspace/>
Mechanism name: sip-message<vspace/>
Mechanism URI: SIP/SIPS as specified in <xref target="RFC3261">RFC 3261</xref><vspace/>
Mechanism-specific options: none<vspace/>
Standards Track/IESG-approved experimental RFC number: [RFC XXXX]<vspace/>
Person and email address to contact for further information:<vspace/>
See authors of [RFC XXXX]
</t>
</section>
<section title="Acknowledgements">
<t>
This document borrows some text from draft-ietf-sieve-notify-xmpp
<xref target="RFC5437"/>.
</t>
<t>
Henning Schulzrinne (hgs@cs.columbia.edu) was a special contributor to this document,
with early work and reviews.
</t>
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119; <!-- Keywords -->
&RFC5228; <!-- Sieve -->
&RFC5435; <!-- Notify -->
&RFC3261; <!-- SIP -->
&RFC3428; <!-- SIP IM -->
&RFC3629; <!-- UTF-8 -->
</references>
<references title="Informative References">
&RFC3856; <!-- SIP presence -->
&RFC5437; <!-- Notify XMPP -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:27:31 |