Network Working Group P. Saint-Andre
Request for Comments: 5437 Cisco
Category: Standards Track A. Melnikov
Isode Limited
January 2009
Sieve Notification Mechanism:
Extensible Messaging and Presence Protocol (XMPP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber.
この文書では、通知はまた、Jabberのとして知られている拡張メッセージングおよびプレゼンスプロトコル（XMPP）、上で送信されるように、通知のためのふるい延長のプロファイルを記述する。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Terminology ................................................3
2. Definition ......................................................3
2.1. Notify Parameter "method" ..................................3
2.2. Test notify_method_capability ..............................3
2.3. Notify Tag ":from" .........................................4
2.4. Notify Tag ":importance" ...................................4
2.5. Notify Tag ":message" ......................................4
2.6. Notify Tag ":options" ......................................4
2.7. XMPP Syntax ................................................4
3. Examples ........................................................6
3.1. Basic Action ...............................................6
3.2. Action with "body" .........................................7
3.3. Action with "body", ":importance", ":message", and
"subject" ..................................................7
3.4. Action with ":from", ":message", ":importance",
"body", and "subject" ......................................8
4. Requirements Conformance ........................................9
5. Internationalization Considerations ............................10
6. Security Considerations ........................................11
7. IANA Considerations ............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
The [NOTIFY] extension to the [SIEVE] mail filtering language is a framework for providing notifications by employing URIs to specify the notification mechanism. This document defines how xmpp URIs (see [XMPP-URI]) are used to generate notifications via the Extensible Messaging and Presence Protocol [XMPP], which is widely implemented in Jabber instant messaging technologies.
[SIEVE]メールフィルタリング言語に[NOTIFY]拡張は、通知メカニズムを指定するURIを使用することにより、通知を提供するためのフレームワークです。この文書では、XMPPのURIは（[XMPP-URI]を参照）が広くJabberのインスタントメッセージング技術で実装されて拡張可能メッセージング及びプレゼンスプロトコル[XMPP]を介して通知を生成するために使用される方法を定義します。
This document inherits terminology from [NOTIFY], [SIEVE], and [XMPP]. In particular, the terms "parameter" and "tag" are used as described in [NOTIFY] to refer to aspects of Sieve scripts, and the term "key" is used as described in [XMPP-URI] to refer to aspects of an XMPP URI.
この文書では、[SIEVE]、[通知]、および[XMPP]から用語を継承します。特に、用語「パラメータ」および「タグ」に記載されているように使用されている[NOTIFY] Sieveスクリプトの態様を参照し、[XMPP-URI]に記載されているように、用語「キー」の側面を指すために使用されますXMPP URI。
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [TERMS].
大文字のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "べきではありません"、 "推奨"、 "すべきである" "ないものと"、 "推奨NOT"、 "MAY"、および "この文書における」OPTIONALは[用語]で説明されるように解釈されるべきです。
The "method" parameter MUST be a URI that conforms to the xmpp URI scheme (as specified in [XMPP-URI]) and that identifies an XMPP account associated with the email inbox. The URI MAY include the resource identifier of an XMPP address and/or the query component portion of an XMPP URI, but SHOULD NOT include an authority component or fragment identifier component. The processing application MUST extract an XMPP address from the URI in accordance with the processing rules specified in [XMPP-URI]. The resulting XMPP address MUST be encapsulated in XMPP syntax as the value of the XMPP 'to' attribute.
「方法」パラメータは、（[XMPP-URI]で指定されるように）XMPP URIスキームに準拠しており、その電子メールの受信トレイに関連付けられたXMPPアカウントを識別するURIでなければなりません。 URIは、XMPPアドレスおよび/またはXMPP URIのクエリコンポーネント部分のリソース識別子を含むことができるが、権限の成分またはフラグメント識別子コンポーネントを含むべきではありません。処理アプリケーションは[XMPP-URI]で指定された処理ルールに従ってURIからXMPPアドレスを抽出する必要があります。結果としてXMPPアドレスが属性「から」XMPPの値としてXMPP構文でカプセル化されなければなりません。
In response to a notify_method_capability test for the "online" notification-capability, an implementation SHOULD return a value of "yes" if it has knowledge of an active presence session (see [XMPP-IM]) for the specified XMPP notification-uri; otherwise, it SHOULD return a value of "maybe" (since typical XMPP systems may not allow a Sieve engine to gain knowledge about the presence of XMPP entities).
それは指定されたXMPP通知-URIのアクティブなプレゼンスセッションの知識を（[XMPP-IM]を参照）を持っていれば、「オンライン」通知機能のためnotify_method_capabilityテストを受けて、実装が「はい」の値を返す必要があります。 （典型的なXMPPシステムはふるいエンジンはXMPPエンティティの存在についての知識を得ることを許可しないかもしれないので）それ以外の場合は、「多分」の値を返すべきです。
If included, the ":from" tag MUST be an electronic address that conforms to the "Mailbox" rule defined in [RFC5321]. The value of the ":from" tag MAY be included in the human-readable XML character data of the XMPP notification; alternatively or in addition, it MAY be transformed into formal XMPP syntax, in which case it MUST be encapsulated as the value of an XMPP SHIM (Stanza Headers and Internet Metadata) [SHIM] header named "Resent-From".
含まれている場合、：タグ「から」[RFC5321]で定義された「メールボックス」ルールに準拠する電子アドレスでなければなりません。値「：から」タグがXMPP通知の人間が読めるXML文字データに含まれるかもしれ。代替的にまたは付加的に、それは「憤慨-から」という名前のXMPP SHIM（スタンザヘッダ及びインターネットメタ）SHIM]ヘッダの値としてカプセル化されなければならない場合には、正式なXMPP構文に変換することができます。
The ":importance" tag has no special meaning for this notification mechanism, and this specification puts no restriction on its use. The value of the ":importance" tag MAY be transformed into XMPP syntax (in addition to or instead of including appropriate text in the XML character data of the XMPP <body/> element); if so, it SHOULD be encapsulated as the value of an XMPP SHIM (Stanza Headers and Internet Metadata) [SHIM] header named "Urgency", where the XML character of that header is "high" if the value of the ":importance" tag is "1", "medium" if the value of the ":importance" tag is "2", and "low" if the value of the ":importance" tag is "3".
「：重要」タグは、この通知メカニズムのためには特別な意味を持ちませんし、この仕様は、その使用に制限をかけていません。 「重要」の値タグ（またはその代わりXMPP <BODY />要素のXML文字データに適切なテキストを含むのに加えて）XMPP構文に変換することができます。 「重要」もしそうなら、そのヘッダのXML文字がの値であれば「高」である「緊急」という名前のXMPP SHIM（スタンザヘッダ及びインターネットメタ）SHIM]ヘッダの値としてカプセル化されるべきです「重要」タグである「2」の値が「低」「：重要度」タグが「3」のタグは、の値があれば、「中」、「1」です。
If the ":message" tag is included, that string MUST be transformed into the XML character data of an XMPP <body/> element (where the string is generated according to the guidelines specified in Section 3.6 of [NOTIFY]).
「メッセージ」場合はタグが含まれ、その文字列（文字列が[NOTIFY]のセクション3.6で指定されたガイドラインに従って生成される）XMPP <BODY />要素のXML文字データに変換されなければなりません。
The ":options" tag has no special meaning for this notification mechanism. Any handling of this tag is the responsibility of an implementation.
「：オプション」タグは、この通知メカニズムのための特別な意味を持ちません。このタグの任意の取り扱いは、実装の責任です。
The xmpp mechanism results in the sending of an XMPP message to notify a recipient about an email message. The general XMPP syntax is as follows:
XMPP機構は、電子メールメッセージについて受信者に通知するXMPPメッセージの送信をもたらします。次のように一般的なXMPPの構文は次のとおりです。
o The notification MUST be an XMPP <message/> stanza.
O通知は、XMPP <メッセージ/>スタンザでなければなりません。
o The value of the XMPP 'from' attribute SHOULD be the XMPP address of the notification service associated with the Sieve engine or the XMPP address of the entity to be notified. The value of the XMPP 'from' attribute MUST NOT be generated from the Sieve ":from" tag.
O属性「から」XMPPの値は、ふるいエンジンまたはエンティティのXMPPアドレスに関連付けられた通知サービスのXMPPアドレスが通知されるようにあるべきです。属性「から」XMPPの値はふるいから生成されてはならない「：から」タグ。
o The value of the XMPP 'to' attribute MUST be the XMPP address specified in the XMPP URI contained in the "method" notify parameter.
属性「」のXMPPの値が「方法」に含まれているXMPP URIで指定されたXMPPアドレスでなければなりませんOパラメータを通知します。
o The value of the XMPP 'type' attribute MUST be 'headline' or 'normal'.
O XMPP「タイプ」属性の値は「見出し」または「通常」でなければなりません。
o The XMPP <message/> stanza MUST include a <body/> child element. If the ":message" tag is included in the Sieve script, that string MUST be used as the XML character data of the <body/> element. If not and if the XMPP URI contained in the "method" notify parameter specified a "body" key in the query component, that value SHOULD be used. Otherwise, the XML character data SHOULD be some configurable text indicating that the message is a Sieve notification.
O XMPP <メッセージ/>スタンザは、<BODY />子要素を含まなければなりません。 「：メッセージ」場合はタグがSieveスクリプトに含まれ、その文字列は、<ボディ/>要素のXML文字データとして使用しなければなりません。そうでない場合とXMPP URIが「方法」に含まれている場合には、パラメータを通知するクエリコンポーネントの「本体」キーを指定し、その値が使用されるべきです。それ以外の場合は、XMLの文字データは、メッセージがふるい通知であることを示すいくつかの設定可能なテキストであるべきです。
o The XMPP <message/> stanza MAY include a <subject/> child element. If the XMPP URI contained in the "method" notify parameter specified a "subject" key in the query component, that value SHOULD be used as the XML character data of the <subject/> element. Otherwise, the XML character data SHOULD be some configurable text indicating that the message is a Sieve notification.
O XMPP <メッセージ/>スタンザは<被験者/>子要素を含んでいてもよいです。 XMPP URIは、「メソッド」パラメータを通知するクエリコンポーネントに「対象」キーを指定し、その値が<被験者/>要素のXML文字データとして使用されるべきである。中に含まれる場合それ以外の場合は、XMLの文字データは、メッセージがふるい通知であることを示すいくつかの設定可能なテキストであるべきです。
o The XMPP <message/> stanza SHOULD include a URI, for the recipient to use as a hint in locating the message, encapsulated as the XML character data of a <url/> child element of an <x/> element qualified by the 'jabber:x:oob' namespace, as specified in [OOB]. If included, the URI SHOULD be an Internet Message Access Protocol [IMAP] URL that specifies the location of the message, as defined in [IMAP-URL], but MAY be another URI type that can specify or hint at the location of an email message, such as a URI for an HTTP resource [HTTP] or a Post Office Protocol Version 3 (POP3) mailbox [POP-URL] at which the message can be accessed. It is not expected that an XMPP user agent shall directly handle such a URI, but instead that it shall invoke an appropriate helper application to handle the URI.
受信者がメッセージを見つけるのヒントとして使用するためのXMPP <メッセージ/>スタンザは、URIを含むべきであるO、によって修飾<X />要素の<URL />子要素のXML文字データとしてカプセル化'おしゃべり：X：OOB' 名前空間、[OOB]で指定されるように。含まれている場合、URIは、[IMAP-URL]で定義されているように、メッセージの場所を指定するインターネットメッセージアクセスプロトコル[IMAP] URLにする必要がありますが、指定したり、電子メールの場所を示唆することができ、別のURI型であってもよいですそのようなHTTPリソースのURI [HTTP]またはメッセージがアクセス可能なポストオフィスプロトコルバージョン3（POP3）メールボックス[POP-URL]のようなメッセージ、。 XMPPのユーザエージェントは、直接、そのようなURIを処理しなければならないことが、その代わりに、それはURIを処理するための適切なヘルパーアプリケーションを起動するものと期待されていません。
o The XMPP <message/> stanza MAY include an XMPP SHIM (Stanza Headers and Internet Metadata) [SHIM] header named "Resent-From". If the Sieve script included a ":from" tag, the "Resent-From" value MUST be the value of the ":from" tag; otherwise, the "Resent-From" value SHOULD be the envelope recipient address of the original email message that triggered the notification.
O XMPP <メッセージ/> XMPP SHIM（スタンザヘッダ及びインターネットメタデータ）「憤慨-から」と命名[SHIM]ヘッダーを含むかもしれスタンザ。 Sieveスクリプトが含まれている場合は、「：から」タグ「のResent-から」値は、の値でなければならない「：から」タグ。そうでない場合は、「憤慨し-から」値は、通知をトリガし、元の電子メールメッセージのエンベロープ受信者のアドレスでなければなりません。
In the following examples, the sender of the email has an address of <mailto:juliet@example.org>, the entity to be notified has an email address of <mailto:romeo@example.com> and an XMPP address of romeo@im.example.com (resulting in an XMPP URI of <xmpp:romeo@im.example.com>), and the notification service associated with the Sieve engine has an XMPP address of notify.example.com.
次の例では、電子メールの送信者は、のアドレスを持っている<MAILTO：juliet@example.org>、通知するエンティティは、の電子メールアドレスがある<mailtoの：romeo@example.com>とロミオのXMPPアドレスを@ im.example.com（のXMPP URIをもたらす<XMPP：romeo@im.example.com>）、及びふるいエンジンに関連付けられている通知サービスはnotify.example.comのXMPPアドレスを有しています。
Note: In the following examples, line breaks are included in XMPP URIs solely for the purpose of readability.
注：以下の例では、改行は単に読みやすさのためにXMPPのURIに含まれています。
The following is a basic Sieve notify action with only a method. The XML character data of the XMPP <body/> and <subject/> elements are therefore generated by the Sieve engine based on configuration. In addition, the Sieve engine includes a URI pointing to the message.
以下は、唯一の方法でアクションを通知し、基本的なふるいです。 XMPPのXML文字データ<BODY />と<件名/>要素は、したがって、構成に基づいてふるいエンジンによって生成されます。また、ふるいエンジンは、メッセージにURIポインティングを含みます。
Basic action (Sieve syntax)
基本的なアクション（ふるい構文）
notify "xmpp:romeo@im.example.com"
通知 "XMPP：romeo@im.example.com"
The resulting XMPP <message/> stanza might be as follows:
次のように結果のXMPP <メッセージ/>スタンザは次のようになります。
Basic action (XMPP syntax)
基本的なアクション（XMPP構文）
<message from='notify.example.com' to='romeo@im.example.com' type='headline' xml:lang='en'> <subject>SIEVE</subject> <body><juliet@example.com> You got mail.</body> <x xmlns='jabber:x:oob'> <url> imap://romeo@example.com/INBOX;UIDVALIDITY=385759043/;UID=18 </url> </x> </message>
<メッセージから= 'notify.example.com' to='romeo@im.example.com」TYPE = '見出し' のxml：langの= 'EN'> <被験者> SIEVE </被験者> <BODY>＆LT;ジュリエット@ example.com＆GT。あなたは電子メールを得た。</ BODY> <Xのxmlns = 'ジャバー：X：OOB'> <URL> IMAP：。//romeo@example.com/INBOX; = 385759043 / UIDVALIDITY; UID = 18 </ URL> </ X > </メッセージ>
The following action contains a "body" key in the query component of the XMPP URI but no ":message" tag in the Sieve script. As a result, the XML character data of the XMPP <body/> element in the XMPP notification is taken from the XMPP URI. In addition, the Sieve engine includes a URI pointing to the message.
次のアクションは、「身体」XMPP URIのクエリコンポーネントでキーが、ありませんが含まれています「：メッセージ」Sieveスクリプト内のタグ。その結果、XMPPのXML文字データは、<ボディ/> XMPP通知の要素は、XMPP URIから取られています。また、ふるいエンジンは、メッセージにURIポインティングを含みます。
Action with "body" (Sieve syntax)
「体」（ふるい構文）とアクション
notify "xmpp:romeo@im.example.com?message ;body=Wherefore%20art%20thou%3F"
通知 "XMPP：romeo@im.example.comメッセージ、本体=それゆえ％20art％20thou％3F"
The resulting XMPP <message/> stanza might be as follows.
次のように得られたXMPP <メッセージ/>スタンザがあるかもしれません。
Action with "body" (XMPP syntax)
「体」（XMPP構文）とアクション
<message from='notify.example.com' to='romeo@im.example.com' type='headline' xml:lang='en'> <subject>SIEVE</subject> <body>Wherefore art thou?</body> <x xmlns='jabber:x:oob'> <url> imap://romeo@example.com/INBOX;UIDVALIDITY=385759044/;UID=19 </url> </x> </message>
<= 'notify.example.com' to='romeo@im.example.com」TYPE = '見出し' のxml：langの= 'からメッセージEN'> <被験者> SIEVE </被験者> <BODY>それゆえアートなた？ </ BODY> <Xのxmlns = 'おしゃべり：X：OOB'> <URL> IMAP：//romeo@example.com/INBOX; UIDVALIDITY = 385759044 /; UID = 19 </ URL> </ X> </メッセージ>
The following action specifies an ":importance" tag and a ":message" tag in the Sieve script, as well as a "body" key and a "subject" key in the query component of the XMPP URI. As a result, the ":message" tag from the Sieve script overrides the "body" key from the XMPP URI when generating the XML character data of the XMPP <body/> element. In addition, the Sieve engine includes a URI pointing to the message.
「：重要」タグとA「：メッセージ」Sieveスクリプト内のタグだけでなく、「身体」キーとXMPP URIのクエリコンポーネントの「件名」キー次のアクションを指定します。その結果、「：メッセージ」XMPP <ボディ/>要素のXML文字データを生成するときにSieveスクリプトからタグがXMPP URIから「体」キーを上書きします。また、ふるいエンジンは、メッセージにURIポインティングを含みます。
Action with "body", ":importance", ":message", and "subject" (Sieve syntax)
「：重要性」、「：メッセージ」、および「件名」（ふるい構文）「ボディ」、とアクション
notify :importance "1" :message "Contact Juliet immediately!" "xmpp:romeo@im.example.com?message ;body=You%27re%20in%20trouble ;subject=ALERT%21"
通知：重要「1」：メッセージ「コンタクトジュリエットすぐに！」 "XMPP：？romeo@im.example.comメッセージ;ボディ=あなた％27re％20IN％20trouble;主題= ALERTの21％"
The resulting XMPP <message/> stanza might be as follows.
次のように得られたXMPP <メッセージ/>スタンザがあるかもしれません。
Action with "body", ":importance", ":message", and "subject" (XMPP syntax)
「：重要性」、「：メッセージ」、および「件名」（XMPP構文）「ボディ」、とアクション
<message from='notify.example.com' to='romeo@im.example.com' type='headline' xml:lang='en'> <subject>ALERT!</subject> <body>Contact Juliet immediately!</body> <headers xmlns='http://jabber.org/protocol/shim'> <header name='Urgency'>high</header> </headers> <x xmlns='jabber:x:oob'> <url> imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20 </url> </x> </message>
<メッセージから= 'notify.example.com' to='romeo@im.example.com」タイプ= '見出し' のxml：LANG = 'EN'>！<対象> ALERT </件名> <身体>連絡先ジュリエットすぐ！</ BODY> <ヘッダのxmlns = 'HTTP：//jabber.org/protocol/shim'> <ヘッダ名= '緊急'>高</ヘッダ> </ヘッダ> <Xのxmlns = 'おしゃべり：X：OOB 「> <URL> IMAP：//romeo@example.com/INBOX; UIDVALIDITY = 385759045 /; UID = 20 </ URL> </ X> </メッセージ>
3.4. Action with ":from", ":message", ":importance", "body", and "subject"
3.4. アクション「：から」「：メッセージ」、「：重要性」、「ボディ」、および「件名」、
The following action specifies a ":from" tag, an ":importance" tag, and a ":message" tag in the Sieve script, as well as a "body" key and a "subject" key in the query component of the XMPP URI. As a result, the ":message" tag from the Sieve script overrides the "body" key from the XMPP URI when generating the XML character data of the XMPP <body/> element. In addition, the Sieve engine includes a URI pointing to the message, as well as an XMPP SHIM (Stanza Headers and Internet Metadata) [SHIM] header named "Resent-From" (which encapsulates the value of the ":from" tag).
「から」「：重要度」タグ、およびAタグ、「メッセージ」Sieveスクリプトタグ、ならびに「本体」キーとのクエリコンポーネントの「件名」をキーとして、以下のアクションが指定しますXMPP URI。その結果、「：メッセージ」XMPP <ボディ/>要素のXML文字データを生成するときにSieveスクリプトからタグがXMPP URIから「体」キーを上書きします。また、ふるいエンジンは、（「：から」タグの値をカプセル化する）メッセージ、ならびに「憤慨-から」という名前のXMPP SHIM（スタンザヘッダ及びインターネットメタ）SHIM]ヘッダを指し示すURIを含みます。
Action with ":from", ":importance", ":message", "body", and "subject" (Sieve syntax)
アクション「：から」、「：重要性」、「：メッセージ」、「ボディ」、および「件名」（ふるい構文）
notify :from "romeo.my.romeo@example.com" :importance "1" :message "Contact Juliet immediately!" "xmpp:romeo@im.example.com?message ;body=You%27re%20in%20trouble ;subject=ALERT%21"
通知：「romeo.my.romeo@example.com」から：重要「1」：メッセージ「コンタクトジュリエットすぐに！」 "XMPP：？romeo@im.example.comメッセージ;ボディ=あなた％27re％20IN％20trouble;主題= ALERTの21％"
The resulting XMPP <message/> stanza might be as follows.
次のように得られたXMPP <メッセージ/>スタンザがあるかもしれません。
Action with ":from", ":importance", ":message", "body", and "subject" (XMPP syntax)
アクション "：から"、 "：重要性"、 "：メッセージ"、 "ボディ"、および "件名"（XMPP構文）
<message from='notify.example.com' to='romeo@im.example.com' type='headline' xml:lang='en'> <subject>ALERT!</subject> <body>Contact Juliet immediately!</body> <headers xmlns='http://jabber.org/protocol/shim'> <header name='Resent-From'>romeo.my.romeo@example.com</header> <header name='Urgency'>high</header> </headers> <x xmlns='jabber:x:oob'> <url> imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=21 </url> </x> </message>
<メッセージから= 'notify.example.com' to='romeo@im.example.com」タイプ= '見出し' のxml：LANG = 'EN'>！<対象> ALERT </件名> <身体>連絡先ジュリエットすぐ！</ body>の<ヘッダーのxmlns = 'のhttp：//jabber.org/protocol/shim'> <ヘッダ名= 'のResent-から'> romeo.my.romeo@example.com </ヘッダ> <ヘッダ名= '緊急'>高</ヘッダ> </ヘッダ> <Xのxmlns = 'おしゃべり：X：OOB'> <URL> IMAP：//romeo@example.com/INBOX; = 385759045 / UIDVALIDITY; UID = 21 </ URL> </ X> </メッセージ>
Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve notification methods. The conformance of the xmpp notification mechanism is provided here.
[NOTIFY]のセクション3.8は、ふるいの通知方法のための要件のセットを指定します。 XMPP通知メカニズムの適合性は、ここで提供されます。
1. An implementation of the xmpp notification method SHOULD NOT modify the final notification text (e.g., to limit the length); however, a given deployment MAY do so (e.g., if recipients pay per character or byte for XMPP messages). Modification of characters themselves should not be necessary, since XMPP character data is encoded in [UTF-8].
1. XMPP通知方法の実装は、最終的な通知テキスト（例えば、長さを制限するために）変更しないでください。 （受信者がXMPPメッセージのための文字またはバイトごとに支払う場合、例えば）しかし、与えられた展開がそうするかもしれません。 XMPPの文字データが[UTF-8]でエンコードされているので、文字そのものの変更は、必要ありません。
2. An implementation MAY ignore parameters specified in the ":from", ":importance", and ":options" tags.
「：から」、「：重要性」、および「：オプションの」タグ2.実装がで指定されたパラメータを無視してもよいです。
3. There is no recommended default message for an implementation to include if the ":message" tag is not specified.
「：メッセージ」タグ指定されていない3.場合は含まれるように、実装のための推奨されるデフォルトのメッセージはありません。
4. A notification sent via the xmpp notification method MAY include a timestamp in the textual message.
4. XMPP通知方法を介して送信される通知は、テキストメッセージにタイムスタンプを含むかもしれません。
5. The value of the XMPP 'from' attribute MUST be the XMPP address of the notification service associated with the Sieve engine. The value of the Sieve ":from" tag MAY be transformed into the value of an XMPP SHIM (Stanza Headers and Internet Metadata) [SHIM] header named "Resent-From".
前記属性「から」XMPPの値は、ふるいエンジンに関連付けられている通知サービスのXMPPアドレスでなければなりません。ふるいの値「：から」タグ「再送-から」という名前のXMPP SHIM（スタンザヘッダ及びインターネットメタ）SHIM]ヘッダの値に変換することができます。
6. The value of the XMPP 'to' attribute MUST be the XMPP address specified in the XMPP URI contained in the "method" parameter.
6.属性「から」XMPPの値は、「方法」のパラメータに含まれるXMPP URIで指定されたXMPPアドレスでなければなりません。
7. In accordance with [XMPP-URI], an implementation MUST ignore any URI action or key it does not understand (i.e., the URI MUST be processed as if the action or key were not present). It is RECOMMENDED to support the XMPP "message" query type (see [QUERIES]) and the associated "body" and "subject" keys, which SHOULD be mapped to the XMPP <body/> and <subject/> child elements of the XMPP <message/> stanza, respectively. However, if included, then the Sieve notify ":message" tag MUST be mapped to the XMPP <body/> element, overriding the "body" key (if any) included in the XMPP URI.
7. [XMPP-URI]に従って、実装は任意のURIアクションを無視するか（アクションまたはキーが存在しないかのように、すなわち、URIが処理されなければならない）、それは理解していないキー入力しなければなりません。 XMPP「メッセージ」クエリの種類（[クエリーを]参照）と関連した「本体」とXMPP <BODY />との<主題/>子要素にマッピングされるべき「対象」キーをサポートするために推奨されますそれぞれXMPP <メッセージ/>スタンザ、。含まれる場合は、その後、ふるいに通知「：メッセージ」タグ「は、身体」キー（もしあれば）をオーバーライド、XMPP <BODY />要素にマッピングする必要がありXMPP URIに含まれます。
8. An implementation MUST NOT include any other extraneous information not specified in parameters to the notify action.
8.実装は、通知アクションのパラメータで指定されていない他の無関係な情報を含んではいけません。
9. In response to a notify_method_capability test for the "online" notification-capability, an implementation SHOULD return a value of "yes" if it has knowledge of an active presence session (see [XMPP-IM]) for the specified XMPP notification-uri, but only if the entity that requested the test is authorized to know the presence of the associated XMPP entity (e.g., via explicit presence subscription as specified in [XMPP-IM]); otherwise, it SHOULD return a value of "maybe" (since typical XMPP systems may not allow a Sieve engine to gain knowledge about the presence of XMPP entities).
9.それは、アクティブプレゼンスセッションの知識を持っている場合は、「オンライン」通知機能のためnotify_method_capabilityテストを受けて、実装は、指定されたXMPPのために（[XMPP-IM]参照）「はい」の値を返すべきではnotification- URIが、テストを要求されたエンティティは、関連するXMPP実体の存在を知ることを許可されている場合にのみ（で指定された明示的なプレゼンスサブスクリプションを経由して、例えば[XMPP-IM]）; （典型的なXMPPシステムはふるいエンジンはXMPPエンティティの存在についての知識を得ることを許可しないかもしれないので）それ以外の場合は、「多分」の値を返すべきです。
10. An implementation SHOULD NOT attempt to retry delivery of a notification if it receives an XMPP error of type "auth" or "cancel", MAY attempt to retry delivery if it receives an XMPP error of type "wait", and MAY attempt to retry delivery if it receives an XMPP error of "modify", but only if it makes appropriate modifications to the notification (see [XMPP]); in any case, the number of retries SHOULD be limited to a configurable number no less than 3 and no more than 10. An implementation MAY throttle notifications if the number of notifications within a given time period becomes excessive according to local service policy. Duplicate suppression (if any) is a matter of implementation and is not specified herein.
10.実装は、それがタイプ「認証」または「キャンセル」のXMPPエラーを受信した場合、通知の配信を再試行するように試みるべきではありません、それはタイプのXMPPエラーを受信した場合、「待つ」の配信を再試行したり、しようとする場合がありそれは、「変更」のXMPPエラーを受信した場合の配信を再試行し、それが通知に適切な変更を行った場合にのみ（参照[XMPP]）。いずれの場合も、再試行の数が3より小さくない設定可能な数に限定されるべきであり、所与の時間期間内の通知の数がローカルサービスポリシーに応じて過剰になると、それ以上10以下の実装は、通知を絞るなくてもよいです。重複抑制は、（もしあれば）の実装の問題であり、ここで指定されていません。
Although an XMPP address may contain nearly any [UNICODE] character, the value of the "method" parameter MUST be a Uniform Resource Identifier (see [URI]) rather than an Internationalized Resource Identifier (see [IRI]). The rules specified in [XMPP-URI] MUST be followed when generating XMPP URIs.
XMPPアドレスは、ほぼすべての[UNICODE]の文字を含んでいてもよいが、「メソッド」パラメータの値がかなり国際リソース識別子よりユニフォームリソース識別子（[URI]参照）（[IRI]参照）でなければなりません。 XMPP URIを生成する際に、[XMPP-URI]で指定された規則に従わなければなりません。
In accordance with Section 13 of RFC 3920, all data sent over XMPP MUST be encoded in [UTF-8].
RFC 3920のセクション13によれば、XMPPを介して送信されるすべてのデータは、[UTF-8]で符号化されなければなりません。
Depending on the information included, sending a notification can be comparable to forwarding mail to the notification recipient. Care must be taken when forwarding mail automatically, to ensure that confidential information is not sent into an insecure environment. In particular, implementations MUST conform to the security considerations given in [NOTIFY], [SIEVE], and [XMPP].
含まれる情報に応じて、通知を送信する通知受信者にメールを転送するに匹敵することができます。メールを転送する際に注意が機密情報を安全でない環境に送信されないことを保証するために、自動的に取られなければなりません。具体的には、実装は[SIEVE]、[通知]、および[XMPP]で与えられたセキュリティ上の考慮事項に適合しなければなりません。
[NOTIFY] specifies that a notification method MUST provide mechanisms for avoiding notification loops. One type of notification loop can be caused by message forwarding; however, such loops are prevented because XMPP does not support the forwarding of messages from one XMPP address to another. Another type of notification loop can be caused by auto-replies to XMPP messages received by the XMPP notification service associated with the Sieve engine; therefore, such a service MUST NOT auto-reply to XMPP messages it receives.
通知方法は、通知ループを回避するためのメカニズムを提供しなければならないことを指定する[NOTIFY]。通知ループの1つのタイプは、メッセージの転送に起因することができます。 XMPPは別のXMPPアドレスからのメッセージの転送をサポートしていないためしかし、このようなループが防止されます。通知ループの別のタイプは、ふるいエンジンに関連付けられたXMPP通知サービスによって受信されたXMPPメッセージに自動応答によって引き起こされ得ます。そのため、このようなサービスは、受信XMPPメッセージに自動返信してはなりません。
A common use case might be for a user to create a script that enables the Sieve engine to act differently if the user is currently available at a particular type of service (e.g., send notifications to the user's XMPP address if the user has an active session at an XMPP service). Whether the user is currently available can be determined by means of a notify_method_capability test for the "online" notification-capability. In XMPP, information about current network availability is called "presence" (see also [MODEL]). Since [XMPP-IM] requires that a user must approve a presence subscription before an entity can gain access to the user's presence information, a limited but reasonably safe implementation might be for the Sieve engine to request a subscription to the user's presence. The user would then need to approve that subscription request so that the Sieve engine can act appropriately depending on whether the user is online or offline. However, the Sieve engine MUST NOT use the user's presence information when processing scripts on behalf of a script owner other than the user, unless the Sieve engine has explicit knowledge (e.g., via integration with an XMPP server's presence authorization rules) that the script owner is authorized to know the user's presence. While it would be possible to design a more advanced approach to the delegation of presence authorization, any such approach is left to future standards work.
一般的なユースケースは、ユーザーがアクティブなセッションを持っている場合、ユーザーのXMPPアドレスに通知を送信するユーザがサービス（例えば、特定のタイプで現在利用可能である場合にふるいエンジンは異なる動作を可能にするスクリプトを作成するには、ユーザーのためにあるかもしれませんXMPPサービスで）。ユーザーが現在使用可能かどうかを「オンライン」通知機能のためnotify_method_capability試験によって測定することができます。 XMPPでは、現在のネットワークの可用性に関する情報は、「プレゼンス」と呼ばれている（参照[MODEL]）。 [XMPP-IM]は、エンティティは、ユーザーのプレゼンス情報へのアクセスを得ることができる前に、ユーザはプレゼンスサブスクリプションを承認しなければならないことを必要とするのでふるいエンジンは、ユーザーのプレゼンスへのサブスクリプションを要求するために、限られたが、合理的に安全な実装があるかもしれません。ふるいエンジンは、ユーザがオンラインまたはオフラインであるかに応じて適切に行動することができるように、ユーザは、そのサブスクリプション要求を承認する必要があります。しかし、利用者以外のスクリプトの所有者に代わってスクリプトを処理するときにふるいエンジンは（XMPPサーバーのプレゼンス認証ルールとの統合を経て、例えば）明示的な知識を持っていない限り、ふるいエンジンは、ユーザーのプレゼンス情報を使用してはならないスクリプトの所有者は、ユーザーのプレゼンスを知ることが許可されています。それはプレゼンス認証の委任に、より高度なアプローチを設計することが可能であろうが、どのようなアプローチは、将来の標準化作業に任されています。
The following template provides the IANA registration of the Sieve notification mechanism specified in this document:
次のテンプレートは、この文書で指定されたふるい通知メカニズムのIANA登録を提供します。
To: iana@iana.org Subject: Registration of new Sieve notification mechanism Mechanism name: xmpp Mechanism URI: RFC 5122 [XMPP-URI] Mechanism-specific options: none Permanent and readily available reference: RFC 5437 Person and email address to contact for further information: Peter Saint-Andre <registrar@xmpp.org>
iana@iana.org件名：：への新しいふるい通知メカニズムメカニズム名の登録：XMPPメカニズムURI：RFC 5122 [XMPP-URI]メカニズム固有のオプション：なし永久かつ容易に入手可能な参照：RFC 5437人とメールアドレスを連絡しますさらに情報：ピーターサンタンドレ<registrar@xmpp.org>
This information has been added to the list of Sieve notification mechanisms maintained at <http://www.iana.org>.
この情報は、<http://www.iana.org>に維持ふるい通知メカニズムのリストに追加されています。
[NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
。。[通知]メルニコフ、A.、エド、Leiba、B.、エド、Segmuller、W.、およびT.マーティン、 "ふるい電子メールフィルタリング：通知のための拡張"、RFC 5435、2009年1月。
[OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066, August 2006.
"バンドデータのうち、" [OOB]サンアンドレ、P.、XSF XEP 0066、2006年8月。
[QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF XEP 0147, September 2006.
[QUERIES]サンアンドレ、P.、 "XMPP URIスキームクエリコンポーネント"、XSF XEP 0147、2006年9月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and Internet Metadata", XSF XEP 0131, July 2006.
[SHIM]サンアンドレ、P.およびJ.ヒルデブラント、 "スタンザヘッダとインターネットメタデータ"、XSF XEP 0131、2006年7月。
[SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]ギュンター、P.、エド。 。とT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"、RFC 5228、2008年1月。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[用語]ブラドナーの、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[XMPP-URI]サンアンドレ、P.、 "国際化資源識別子（IRIを）および拡張メッセージングおよびプレゼンスプロトコル（XMPP）のためのユニフォームリソース識別子（URI）"、RFC 5122、2008年2月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IMAP-URL] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, November 2007.
[IMAP-URL]メルニコフ、A.とC.ニューマン、 "IMAP URLスキーム"、RFC 5092、2007年11月。
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[MODEL]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[POP-URL] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
[POP-URL] Gellens、R.、 "POP URLスキーム"、RFC 2384、1998年8月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000.
[UNICODE]のUnicodeコンソーシアム、 "Unicode標準、バージョン3.2.0"、2000年。
The Unicode Standard, Version 3.2.0 is defined by The
Unicode Standard, Version 3.0 (Reading, MA, Addison-
Wesley, 2000. ISBN 0-201-61633-5), as amended by the
Unicode Standard Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/) and by the Unicode
Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/).
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"、RFC 3920、2004年10月。
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[XMPP-IM]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：インスタントメッセージングとプレゼンス"、RFC 3921、2004年10月。
Authors' Addresses
著者のアドレス
Peter Saint-Andre Cisco
ピーターサンタンドレシスコ
EMail: psaintan@cisco.com
メールアドレス：psaintan@cisco.com
Alexey Melnikov Isode Limited
アレクセイ・メルニコフISODEリミテッド
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com