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
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
筛选通知机制：SIP消息
Abstract
摘要
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE.
本文档描述了用于通知的Sieve扩展的概要文件，以允许通过SIP消息发送通知。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
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].
Sieve邮件过滤语言[RFC5228]的Notify扩展[RFC5435]是一个通过使用指定通知机制的uri来提供通知的框架。（有关动机和用例的详细信息，请参阅RFC 5435。）本文档定义了如何使用会话启动协议（SIP）URI[RFC3261]通过SIP消息[RFC3428]生成通知。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document inherits terminology from the Sieve email filtering language [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 [RFC3261].
本文档继承了Sieve电子邮件过滤语言[RFC5228]、Sieve通知扩展[RFC5435]和RFC 3261[RFC3261]的术语。
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.
本文档中定义的SIP消息机制导致发送SIP消息请求，以通知收件人电子邮件消息。
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:
“method”参数必须是符合SIP或SIPS URI方案（如RFC 3261[RFC3261]中所规定）的URI，并标识通知的SIP或SIPS收件人。URI可以包括SIP地址的资源标识符部分和URI参数。URI必须包含URI参数“method”，值为“MESSAGE”。例子：
notify "sip:romeo@example.com;method=MESSAGE"
--------------
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".
请注意，未来的规范可能会扩展此文档，并定义使用SIP方法而不是“消息”的筛选通知。
The processing application MUST form a request according to the rules specified in RFC 3261 [RFC3261].
处理应用程序必须根据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.
注意，其他URI方案也可以触发SIP处理，但这里只定义了SIP和SIP。未来的扩展可能会定义通过其他URI方案使用SIP的其他筛选通知方法。
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.
“：from”标记的值必须使用SIP“from”头字段语法；如果指定了“：from”值，该值具有有效语法，并且根据特定于实现的安全检查是有效的（请参阅SIVE Notify[RFC5435]第3.3节），则通知应包括包含“：from”Notify标记值的“from”SIP头字段。如果指定的值无效，则忽略该值。
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.
所有SIP身份验证，包括质询和客户机证书，都应该在筛选引擎的上下文中完成——筛选引擎就是被验证的身份。这避免了与筛选引擎访问最终用户的SIP身份验证凭据相关的安全问题。筛引擎可以使用与所有脚本相同的服务器范围凭据（包括适用的证书）。或者，出于审计目的，它可以在代表不同用户操作时使用不同的筛选引擎凭据集。
See Section 22 of RFC 3261 [RFC3261] for more information about SIP authentication.
有关SIP身份验证的更多信息，请参阅RFC 3261[RFC3261]第22节。
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.
“：options”标记的处理是特定于实现的。本文档不要求存在任何选项，也不定义如何处理选项。
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.
“：重要性”标记旨在传达SIP消息通知的重要性，而不是生成通知的电子邮件消息的重要性。因此，“：importance”标记的值可以转换为SIP“Priority”头字段（除了或不包括在消息体中）。请注意，因为Sieve“：importance”标记只有三个值，所以并非所有SIP“Priority”值都可以在转换中表示。如果完成此转换，“优先级”标题字段的值必须为“紧急”，如果“：重要性”标记的值为“1”；如果“：重要性”标记的值为“2”，则“正常”；如果“：重要性”标记的值为“3”，则“非紧急”。没有到SIP值“emergency”的映射，也没有到可能定义的任何其他值的映射。
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.
如果包含“：message”标记，则必须将其转换为SIP消息的消息体，该消息体的内容类型值必须为“text/plain”，并带有CHARSET=“UTF-8”。如果未包含“：message”标记，将使用默认消息。触发电子邮件消息的“发件人”和“主题”标题字段的值对接收通知的用户特别有用，通常最好将其包含在默认消息中，如下面第3.2节所示。（但是，请参阅安全注意事项，第5节。）如果指定了“：重要性”标记，则默认主体还可能包括该标记的值。
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].
如RFC 3428[RFC3428]第8节所述，实施必须符合SIP消息大小限制。
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.
实现必须忽略它不理解的任何URI参数（必须像处理参数不存在一样处理URI）。URI“body”参数的作用与Sieve“：message”标记相同，它提供SIP消息请求的消息体。如果两者同时存在，则筛分处理必须忽略“主体”参数。
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.
使用“：message”标记比使用“body”参数具有优势。由于“：message”标记是“notify”语句语法的一部分，因此可以更容易地将其包含在脚本中，并使用它执行变量替换[RFC5229]等操作。在“：message”标记中包含非ASCII字符也更容易，因为如果这些字符在URI参数内，则必须对其进行编码，但可以直接包含在UTF-8的SIFE标记值中。
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).
根据尝试传递SIP通知期间返回的SIP错误代码，RFC 3261[RFC3261]中指定了重试传递失败通知的策略。换句话说，与其他一些筛通知方法不同，SIP消息通知的重试由通知协议本身（SIP）控制。
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.
如果没有使用[RFC3856]等SIP扩展，则无法提前告知通知接收方是否在线并能够接收SIP消息。“online”的notify_method_功能测试可能会经常返回此通知方法的“maybe”。
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>.
在以下示例中，电子邮件的发件人的地址为juliet@example.org，要通知的实体的SIP地址为<SIP:romeo@example.com>，通知服务的SIP地址<SIP:notifier@example.com>.
The following is a basic Sieve notify action with only a method:
以下是仅使用一种方法的基本筛选通知操作：
notify "sip:romeo@example.com;method=MESSAGE"
notify "sip:romeo@example.com;method=MESSAGE"
The resulting SIP MESSAGE request might be as follows:
产生的SIP消息请求可能如下所示：
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
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!
<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!"
在上面的示例中，电子邮件是从juliet@example.com并有“主题：立即联系我！”
The following is a more advanced Sieve notify action with a method, importance, subject, and message:
以下是一个更高级的SIVE notify操作，包含方法、重要性、主题和消息：
notify :importance "1"
:message "You got new mail!"
"sip:romeo@example.com;method=MESSAGE?subject=SIEVE"
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
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!
你收到新邮件了！
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.
筛通知[RFC5435]第3.8节规定了筛通知方法的一系列要求。这里提供了一个检查表来显示SIP消息通知方法的一致性。
1. No new Sieve tags have been added to the "notify" action.
1. “通知”操作中未添加新的筛子标签。
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].
2. SIP消息通知方法的实现不应修改最终通知文本，除非符合SIP消息长度限制。出于隐私和保密等原因，部署可能会对通知文本做出操作决策。由于SIP消息正文采用UTF-8[RFC3629]编码，因此无需修改字符本身。
3. An implementation MAY ignore parameters specified in the ":importance" and ":options" tags.
3. 实现可以忽略“：重要性”和“：选项”标记中指定的参数。
4. A default message is suggested in Section 2.5.
4. 第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.
5. 经由SIP消息通知方法发送的通知可以包括包含生成SIP消息通知的时刻的日期时间的日期报头字段。
6. The notification source is identified through the SIP "From:" header field, via the Sieve Notify ":from" tag (see Section 2.2).
6. 通知源通过SIP“From:”标题字段，通过Sieve Notify“：From”标签识别（见第2.2节）。
7. An implementation MUST NOT include any extraneous information not specified in parameters to the notify action.
7. 实现不得包含notify操作参数中未指定的任何无关信息。
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.
8. 实现必须忽略它不理解的任何URI参数（即，必须像操作或参数不存在一样处理URI）。详见第2.6节。
9. The notify_method_capability test for the "online" notification-capability behaves as described in Section 2.7.
9. “在线”通知能力的notify_method_能力测试的行为如第2.7节所述。
10. The policy for retrying delivery of failed notifications is specified in RFC 3261 [RFC3261], as noted in Section 2.6.
10. RFC 3261[RFC3261]中规定了重试发送失败通知的策略，如第2.6节所述。
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.
消息，以确保机密信息不会发送到不安全的环境或通过不安全的通道。根据环境的不同，这可能需要使用SIPS URI，不发送关于主题和/或发送者的信息，或者对消息应用启发式来确定可能发送的内容。
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.
按照RFC 3428的要求，支持SIP消息请求的用户代理必须实现端到端身份验证、主体完整性和主体机密性机制。在撰写本文时，没有广泛部署SIP端到端安全性，因此可能存在无法使用它的情况，即使它是在一端实现的。需要注意的是，这种情况很容易通过中间人和其他被动攻击暴露用户凭据、消息内容和其他私人信息。
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.
sievenotify扩展指定通知方法必须提供避免通知循环的机制。在这种情况下，SIP协议本身防止循环，在通知机制中不需要显式工作。在SIP消息通知可能导致生成另一个SIP消息通知的电子邮件消息的情况下，可能需要通过速率检测和限制进行循环预防。一个实现可能会在给定的时间段内检测到太多的通知、太多由特定发送者触发的通知、太多具有相同主题的通知等，并在一段时间内关闭受影响的通知，或者直到手动干预将其重新打开。
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.
如果SIP消息请求可能由消息计费，或者使用SIP消息请求可能会耗尽用户的消息配额，则通过此机制发出的通知可能会出现这样的情况，即某人使用大量消息生成大量通知将给收件人造成重大费用。由于攻击者无法从外部判断情况是否如此，因此此类攻击可能是随机或滋扰性攻击。然而，当用户设置SIP消息通知时，可能会警告他们潜在的成本。
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.
筛基规范[RFC5228]、筛通知扩展[RFC5435]和RFC 3261[RFC3261]中给出的其他安全注意事项也与本文件相关。
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>.
以下模板提供了本文档中指定的筛选通知机制的IANA注册。此信息已添加到维护的筛选通知机制列表中<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: [RFC6468]
Person and email address to contact for further information:
See authors of [RFC6468]
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]
This document borrows some text from RFC 5437 [RFC5437].
本文档借用了RFC 5437[RFC5437]中的一些文本。
Henning Schulzrinne (hgs@cs.columbia.edu) was a special contributor to this document, with early work and reviews.
亨宁·舒尔兹林内(hgs@cs.columbia.edu)是本文件的特别贡献者，早期工作和评论。
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.
作者要感谢亚当·罗奇和埃里克·伯格的有益评论。Ben Campbell对RAI团队进行了非常彻底的审查，并进行了后续审查，以确保我们满意地解决了他的所有问题。他们的投入大大改进了这份文件。
Qian Sun contributed text to this document.
钱孙为这份文件提供了文本。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]Guenther，P.和T.Showalter，“筛选：电子邮件过滤语言”，RFC 5228，2008年1月。
[RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
[RFC5435]Melnikov，A.，Leiba，B.，Segmuller，W.，和T.Martin，“筛选电子邮件过滤：通知扩展”，RFC 54352009年1月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[RFC5229]Homme，K.，“筛选电子邮件过滤：变量扩展”，RFC5292008年1月。
[RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)", RFC 5437, January 2009.
[RFC5437]Saint Andre，P.和A.Melnikov，“筛选通知机制：可扩展消息和存在协议（XMPP）”，RFC 5437，2009年1月。
Authors' Addresses
作者地址
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode Limited TW12 2BX
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
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/
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
中国广东省深圳市龙岗区坂田李克鹏华为技术有限公司华为基地邮编：518129
Phone: +86-755-28974289
EMail: likepeng@huawei.com
Phone: +86-755-28974289
EMail: likepeng@huawei.com