[要約] RFC 6468は、Sieve通知メカニズムの一部としてSIP MESSAGEを使用する方法について説明しています。このRFCの目的は、Sieveスクリプトの実行結果を通知するための効果的なメカニズムを提供することです。
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.
このドキュメントでは、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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 Mailフィルタリング言語[RFC5228]へのNotify Extension [RFC5435]は、通知メカニズムを指定するURIを使用して通知を提供するためのフレームワークです。（動機とユースケースの詳細については、RFC 5435を参照してください。）このドキュメントは、SIPメッセージ[RFC3428]を介して通知を生成するためにセッション開始プロトコル（SIP）URIS [RFC3261]を使用する方法を定義しています。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document inherits terminology from the Sieve email filtering language [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 [RFC3261].
このドキュメントは、シーブメールフィルタリング言語[RFC5228]、シーブ通知拡張[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:
「メソッド」パラメーターは、SIPまたはSIPS URIスキーム（RFC 3261 [RFC3261]で指定）に準拠し、通知のSIPまたはSIPのレシピエントを識別するURIでなければなりません。URIには、SIPアドレスのリソース識別子部分とURIパラメーターが含まれる場合があります。URIには、値「メッセージ」を備えたURIパラメーター「メソッド」を含める必要があります。例：
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スキームを使用する他のふるい通知方法を定義する場合があります。
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」値が指定され、有効な構文があり、実装固有のセキュリティチェックに従って有効である場合（Sieve Notify [RFC5435]のセクション3.3を参照）、通知には「SIP Headerフィールド」を含む「From」を含める必要があります。"：from" notifyタグの値。指定された値が有効でない場合、無視されます。
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認証資格情報にアクセスできるセキュリティの問題が回避されます。Sieve Engineは、すべてのスクリプトで同じであるサーバー全体の資格情報（該当する証明書を含む）を使用できます。あるいは、監査目的で、異なるユーザーに代わって操作する際に、さまざまなシーブエンジン資格情報を使用する場合があります。
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メッセージ通知の重要性を伝えることを目的としています。したがって、「重要な」タグの値は、メッセージの本文に含める代わりに、またはその代わりに、「優先度」ヘッダーフィールドに変換される場合があります。Sieve "：calture"タグには3つの値のみがあり、すべてのSIP「優先度」値が変換で表現できるわけではないため、注意してください。この変換が行われた場合、「優先度」ヘッダーフィールドの値は、「重要な」タグが「1」、「通常」の場合は「緊急」でなければなりません。2 "、および「重要な「タグ」の値が「3」の値の場合、「非緊急」。SIP値の「緊急」や定義される可能性のある追加値へのマッピングはありません。
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.
「：メッセージ」タグが含まれている場合、charset = "utf-8"を使用して「テキスト/プレーン」のコンテンツタイプの値が必要なSIPメッセージのメッセージ本文に変換する必要があります。「：メッセージ」タグが含まれていない場合、デフォルトのメッセージが使用されます。Triggering Emailメッセージの「From」および「subject」ヘッダーフィールドの値は、通知を受信するユーザーにとって特に役立ち、デフォルトメッセージにそれらを含めることは、以下のセクション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の「ボディ」パラメーターは、SIVEと同じ目的を使用できます。メッセージ「タグ」で、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.
「：メッセージ」タグを使用すると、「ボディ」パラメーターを使用することよりも利点があります。「：メッセージ」タグは「notify」ステートメント構文の一部であるため、スクリプトに含める方が簡単で、可変置換[RFC5229]などを行うことができます。また、ASCII以外の文字を「：メッセージ」タグに含める方が簡単です。なぜなら、そのような文字はURIパラメーター内にある場合はエンコードする必要があるが、Siveタグ値のUTF-8に直接含めることができるからです。
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メッセージを受信できるかどうかを事前に判断することは不可能です。「オンライン」のnotify_method_capabilityテストが、この通知方法の「おそらく」を頻繁に返すことを期待してください。
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：romeo@example.com>のSIPアドレスがあり、通知サービスにはSIPアドレスがあります<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:
結果の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
<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:
以下は、方法、重要性、主題、およびメッセージを備えたより高度なふるい通知アクションです。
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!
あなたは新しいメールを受け取りました！
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.
SIVE通知[RFC5435]のセクション3.8は、ふるい通知方法の一連の要件を指定しています。ここでは、SIPメッセージ通知方法の適合性を示すためにチェックリストが提供されています。
1. No new Sieve tags have been added to the "notify" action.
1. 「Notify」アクションに新しいふるいタグは追加されていません。
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. 通知ソースは、「from： "ヘッダーフィールド、シーブ通知を介して」：from" tag（セクション2.2を参照）から識別されます。
7. An implementation MUST NOT include any extraneous information not specified in parameters to the notify action.
7. 実装には、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.
8. 実装は、理解できないURIパラメーターを無視する必要があります（つまり、アクションまたはパラメーターが存在しないかのようにURIを処理する必要があります）。詳細については、セクション2.6を参照してください。
9. The notify_method_capability test for the "online" notification-capability behaves as described in Section 2.7.
9. セクション2.7で説明されているように、「オンライン」通知能力の容認性のnotify_method_capabilityテスト。
10. The policy for retrying delivery of failed notifications is specified in RFC 3261 [RFC3261], as noted in Section 2.6.
10. セクション2.6に記載されているように、失敗した通知を再送信するためのポリシーは、RFC 3261 [RFC3261]で指定されています。
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.
Sieve Notify Extensionは、通知方法が通知ループを回避するためのメカニズムを提供する必要があることを指定します。この場合、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メッセージ通知を設定したときに潜在的なコストについて警告される可能性があります。
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>.
次のテンプレートは、このドキュメントで指定されたSIEVE通知メカニズムの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]
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.
Henning Schulzrinne（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.
著者は、Adam RoachとEric Burgerに有益なコメントをしてくれたことに感謝します。ベン・キャンベルは非常に徹底的なRAIチームのレビューと、彼のすべての問題を十分に解決したことを確認するためのフォローアップレビューを行いました。このドキュメントは、入力によって大幅に改善されました。
Qian Sun contributed text to this document.
Qian Sunはこの文書にテキストを寄付しました。
[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：SESSION INTIANIATION Protocol」、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 3428、2002年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、「Sieve：An Email Filtering Language」、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、「Sieve Emailフィルタリング：通知の拡張」、RFC 5435、2009年1月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[RFC5229] Homme、K。、「Sieve Emailフィルタリング：変数拡張」、RFC 5229、2008年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。and 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
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
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
Kepeng Li Huawei Technologies Huawei Base、Bantian、Longgang District Shenzhen、Guangdong 518129 P.R. China
Phone: +86-755-28974289
EMail: likepeng@huawei.com