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
Abstract
抽象
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE.
この文書では、通知は、SIP MESSAGEを介して送信されるように、通知のためのふるい延長のプロファイルを記述する。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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].
ふるいのメールフィルタリング言語[RFC5228]の拡張[RFC5435]を通知する通知メカニズムを指定するURIを使用することによって、通知を提供するためのフレームワークです。 （モチベーションの詳細については、RFC 5435を参照し、例を使用しています。）この文書では、どのようにセッション開始プロトコル（SIP）URIを定義して、[RFC3261]は、SIP MESSAGE [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].
この文書のキーワード "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].
この文書では、Sieveメールフィルタリング言語[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に準拠又は（RFC 3261で指定された[RFC3261]のように）、それはSIPを識別または通知の受信者をSIPS URIスキームをSIPS URIでなければなりません。 URIは、SIPアドレスとURIパラメータのリソース識別子部分を含むことができます。 URIは、値「MESSAGE」と「方法」、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".
将来の仕様はこの文書を拡張し、「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とSIPSがここで定義されていることに注意してください。将来の拡張機能は、他の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.
値「：から」タグは、ヘッダフィールドの構文「から」SIPを使用する必要があります。もし「から」の値が指定され、有効な構文を有し、実装固有のセキュリティチェックは、通知が含む「から」SIPヘッダフィールドを含むべきである（[RFC5435]はNOTIFYふるいのセクション3.3を参照）に従って有効です「：から」通知タグの値。指定された値が有効でない場合、それは無視されます。
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認証は、ふるいエンジンのコンテキストで実行する必要があります - ふるいエンジンが認証されているIDです。これは、エンドユーザーの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.
「：オプション」の取り扱いタグは、実装固有のものです。このドキュメントは、任意のオプションの存在を必要とせず、オプションがどのように処理されるかを定義しません。
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メッセージ通知ではなく、通知を生成した電子メールメッセージの重要性の重要性を伝えることを目的としています。値「：重要度」タグMAYは、従って、（メッセージの本文に含め、または代わりに加えて）SIP「優先度」ヘッダフィールドに変換されます。 「：重要」タグ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」と「プレーンテキスト/」のContent-Typeの値を持たなければならないSIPメッセージのメッセージボディに変換されなければなりません。 「：メッセージ」場合はタグが含まれていない、デフォルトのメッセージが使用されます。 「から」とトリガーEメールメッセージの「件名」ヘッダフィールドの値は、以下のセクション3.2に示されるように、一般的には良い考えであり、ユーザーが通知を受信し、デフォルトのメッセージに含めるに特に有用です。 1が指定されている場合、タグ：「重要性」（ただし、第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パラメータを無視しなければなりません。 SIPメッセージ要求のメッセージボディを提供する、タグ：「メッセージ」URI「身体」パラメータは、ふるいと同じ目的を果たすことができます。両方が同時に存在する場合、ふるい処理が「本体」パラメータを無視しなければなりません。
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.
「：メッセージ」を使用してタグ「ボディ」パラメータを使用して比べて利点があります。 「：メッセージ」このため、このタグは「通知」文の構文の一部であり、スクリプトに含める容易にすることができ、このようなことで、変数の置換[RFC5229]のように物事を行います。そのような文字は、彼らがURIパラメータの範囲内であれば、符号化する必要があるが、ふるいタグ値でUTF-8に直接含めることができますので、タグ：「メッセージ」には、非ASCII文字を含めることも簡単です。
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のアドレスを持って、通知するエンティティは、<一口：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"
通知 "SIP：romeo@example.com;メソッド= 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経由：SIP / 2.0 / TCP notifier.example.com;ブランチ= z9hG4bK776sgdkseマックス・フォワード：70から：SIP：notifier@example.com;タグは= 32328へ：SIP：ロメオ@ example.comコールIDを：asd88asd77a@1.2.3.4ののCSeq：1 MESSAGE日：土、2010年11月13日23時29分00秒GMTのコンテンツタイプ：text / plainのコンテンツの長さ：53
<juliet@example.com> wrote: Contact me immediately!
<juliet@example.com>書いた：すぐに私に連絡して！
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"
通知：重要「1」：メッセージ「あなたは新しいメールを持って！」 "SIP：？romeo@example.com;方法= MESSAGE対象= 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経由：SIP / 2.0 / TCP notifier.example.com;ブランチ= z9hG4bK776sgdkseマックス・フォワード：70から：SIP：notifier@example.com;タグは= 32328へ：SIP：ロメオ@ example.com件名：SIEVE優先度：緊急コールID：asd88asd77a@1.2.3.4ののCSeq：1 MESSAGE日：金、2011年4月8日6時54分00秒GMTのコンテンツタイプ：text / plainのコンテンツの長さ：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.
ふるいのセクション3.8 [RFC5435]を通知ふるい通知方法の要件のセットを指定します。チェックリストは、SIPメッセージの通知方法の適合性を示すために、ここで提供されます。
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.実装がで指定されたパラメータを無視してもよいです。
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.
前記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を介して識別される「から」タグ（セクション2.2を参照）。
7. An implementation MUST NOT include any extraneous information not specified in parameters to the notify action.
7.実装は通知アクションにパラメータで指定されていない余分な情報を含んではいけません。
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.
（アクションまたはパラメータが存在しないかのように、すなわち、URIを処理しなければなりません）8.実装は、それが理解できない任意のURIパラメータを無視しなければなりません。詳細については、2.6節を参照してください。
9. The notify_method_capability test for the "online" notification-capability behaves as described in Section 2.7.
2.7節で説明したように9.「オンライン」通知機能のためnotify_method_capabilityテストは動作します。
10. The policy for retrying delivery of failed notifications is specified in RFC 3261 [RFC3261], as noted in Section 2.6.
セクション2.6で述べたように失敗した通知の再試行送達のため10.ポリシーは、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のエンドツーエンドのセキュリティの広範な展開が存在しないので、それは一方の端部に実装されていても、それを使用することができない場合があることができます。それは、このような状況ではなman-in-the-middleおよびその他の受動的攻撃を経由してユーザーの資格情報の暴露、メッセージの内容、およびその他の個人情報に開いていることに注意することが重要です。
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.
ふるいは、拡張子を通知する通知方法が通知ループを回避するためのメカニズムを提供しなければならないことを指定します。この場合、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>.
次のテンプレートは、この文書で指定されたふるい通知メカニズムの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件名：新しいふるい通知メカニズムメカニズム名の登録：SIPメッセージのメカニズムURI：SIP / RFC 3261で指定されているようSIPS [RFC3261]メカニズム固有のオプション：なし標準化過程/ IESGが承認した実験的RFC番号：詳細のために連絡するために[RFC6468] PersonとEメールアドレス：[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.
ヘニング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.
作者は彼らの役に立つコメントをアダムローチとエリックバーガーに感謝したいと思います。ベン・キャンベルは非常に徹底したRAI-チームのレビューだけでなく、私たちは十分に彼の問題のすべてを解決してくださいするにはフォローアップ審査を行いました。この文書では、大幅に彼らの入力によって改善されました。
Qian Sun contributed text to this document.
銭Sunは、この文書にテキストを貢献しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]キャンベル、B.、ローゼンバーグ、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]ギュンター、P.およびT.ショーウォルター監督、 "ふるい：メールフィルタリング言語"、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]メルニコフ、A.、Leiba、B.、Segmuller、W.、およびT.マーティン、 "ふるい電子メールフィルタリング：通知のための拡張"、RFC 5435、2009年1月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]ローゼンバーグ、J.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、2004年8月。
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[RFC5229]オム、K.、 "ふるいメールフィルタリング：変数の拡張"、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]サンアンドレ、P.およびA.メルニコフ、 "ふるい通知メカニズム：拡張メッセージングおよびプレゼンスプロトコル（XMPP）"、RFC 5437、2009年1月。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/
電子メール：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/
電話：+1 646 827 0648 Eメール：barryleiba@computer.org URI：http://internetmessagingtechnology.org/
Kepeng Li Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P.R. China
KE鵬リットルIH UAは技術胡ベース、禁止の日、長い剛性地区としてAが真で、GU Gケース洞518129中華人民共和国です
Phone: +86-755-28974289 EMail: likepeng@huawei.com
電話：+ 86-755-28974289電子メール：likepeng@huawei.com