RFC 6132 - Sieve Notification Using Presence Information 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6132
タイトル : RFC 6132 - 存在情報を使用したふるい通知
翻訳編集 : 自動生成

[要約] RFC 6132は、プレゼンス情報を使用したSieve通知に関する規格です。このRFCの目的は、Sieveスクリプトの実行中にプレゼンス情報を使用して通知を送信する方法を定義することです。

Internet Engineering Task Force (IETF)                         R. George
Request for Comments: 6132                                      B. Leiba
Category: Standards Track                            Huawei Technologies
ISSN: 2070-1721                                                July 2011

Sieve Notification Using Presence Information

存在情報を使用したふるい通知

Abstract

概要

This is a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the notify_method_capability feature.

これは、Sieve Mailのフィルタリング言語通知拡張機能のさらなる拡張機能であり、notify_method_capability機能を介してチェックされる可能性のある存在情報を定義します。

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/rfc6132.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6132で取得できます。

著作権表示

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.  Terminology Used in This Document . . . . . . . . . . . . . 2
   2.  Testing Presence Information  . . . . . . . . . . . . . . . . . 2
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8

1. Introduction

1. はじめに

Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to a user's current situation. Presence information provides some information about the user that would be useful to have access to in these cases. The Notification extension [RFC5435] defines a mechanism to test for presence (the notify_method_capability feature), and defines one test for presence (the "online" notification-capability, described in Section 5 of RFC 5435). This extension defines more presence tests by registering additional notification-capability parameters in the IANA registry, allowing testing of a wider variety of presence information.

時には、ユーザーの現在の状況に通知[RFC5228]を調整することが望ましい場合があります。プレゼンス情報は、これらの場合にアクセスすると便利なユーザーに関する情報を提供します。通知拡張機能[RFC5435]は、存在をテストするメカニズム（Notify_Method_Capability機能）を定義し、存在の1つのテスト（RFC 5435のセクション5で説明されている「オンライン」通知の能力）を定義します。この拡張機能は、IANAレジストリに追加の通知能力パラメーターを登録することにより、より多くの存在テストを定義し、幅広い存在情報のテストを可能にします。

1.1. Terminology Used in This Document

1.1. このドキュメントで使用される用語

The upper-case 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 [RFC2119].

上部ケースのキーワード「必須」、「必須」、「必須」、「「shall」、「shall」、「suff」、 "nove"、 "becommended"、 "may"、 "optional"このドキュメントは、[RFC2119]で説明されているように解釈されます。

2. Testing Presence Information

2. 存在情報のテスト

This extension uses the notify_method_capability test, as defined in the Sieve [RFC5228] Notify extension [RFC5435], to test presence information. When a Sieve event occurs (mail arrives) for a user, a Sieve script running on behalf of that user can present the user's presence URI (in the "notification-uri" parameter) and test a specific item of notification presence as defined below (in the "notification-capability" parameter) against one or more values (in the "key-list" parameter).

この拡張機能は、Sieve [RFC5228]で定義されているように、存在情報をテストするために、Sieve [RFC5228]で定義されているように、notify_method_capabilityテストを使用します。ユーザーのためにふるいイベントが発生した場合（メールが届きます）、ユーザーに代わって実行されているふるいスクリプトがユーザーの存在URI（「Notification-URI」パラメーター）を表示し、以下に定義する特定の通知の存在項目をテストできます（1つ以上の値（「キーリスト」パラメーター）に対して）に対して「通知能力」パラメーター）。

This document defines an initial set of items of notification presence, which may be specified in the notification-capability parameter. It is expected that future extensions will add additional presence items derived from diverse sources, including calendar information, geographic location, and so on.

このドキュメントでは、通知の存在感の初期項目セットを定義します。これは、通知能力パラメーターで指定されている場合があります。将来の拡張機能により、カレンダー情報、地理的位置など、多様なソースから派生した存在アイテムが追加されることが期待されています。

Note that, while the items below are documented as similar to items in Extensible Messaging and Presence Protocol (XMPP) [RFC6121], it is not the intent that this extension be tied to XMPP, nor to any particular source of presence, and flexible implementations will be ready for future extensions. Useful informational references for presence data and formats include Presence Information Data Format (PIDF) [RFC3863], RPID: Rich Presence Extensions to PIDF [RFC4480], and GEOPRIV Presence Information Data Format Location Object (PIDF-LO) [RFC5491].

以下の項目は、拡張可能なメッセージングおよび存在プロトコル（XMPP）[RFC6121]のアイテムに類似していると文書化されていますが、この拡張がXMPPに結び付けられたり、特定の存在ソースと柔軟な実装に結び付けられることは意図ではないことに注意してください。将来の拡張機能の準備が整います。存在データと形式の有用な情報参照には、存在情報データ形式（PIDF）[RFC3863]、RPID：PIDFへのリッチプレゼンス拡張[RFC4480]、およびGeoPRIVプレゼンス情報データ形式の場所オブジェクト（PIDF-LO）[RFC5491]が含まれます。

The script tests the values of notification presence items in the key-list parameter. The values that each item may have are specified in the list below. Note that in addition to the presence values, any item may have the value "unknown" if it is not possible to determine the correct presence value of the item.

スクリプトは、キーリストパラメーター内の通知プレゼンスアイテムの値をテストします。各項目が持っているかもしれない値は、以下のリストに指定されています。存在値に加えて、アイテムの正しい存在値を決定できない場合、すべてのアイテムには「不明」値がある場合があることに注意してください。

If a particular presence item is tested multiple times within the same script execution context, implementations MUST present the same value each time (for example, by caching the value on first use). This provides consistency within a single execution.

特定の存在アイテムが同じスクリプト実行コンテキスト内で複数回テストされている場合、実装は毎回同じ値を表示する必要があります（たとえば、最初の使用時に値をキャッシュすることにより）。これにより、単一の実行内で一貫性が提供されます。

Supported presence items are as follows:

サポートされているプレゼンスアイテムは次のとおりです。

busy: An indication of whether the user is considered "busy" now (the value "yes") or not (the value "no"), or "unknown" if it cannot be determined. The meaning of "busy" is left to the implementation, and may be a state that's synthesized from other information (including "show", below).

ビジー：ユーザーが現在「忙しい」と見なされているか（値「はい」）（値「いいえ」」と見なされているか、決定できない場合は「不明」かどうかを示しています。「ビジー」の意味は実装に残されており、他の情報から合成される状態である可能性があります（以下の「show」を含む）。

show: The availability status of the user, formally specified. Note that this is similar to the presence element with the same name that's defined in Section 4.7.2.1 of RFC 6121 [RFC6121]. The value of this item is one of the following:

表示：正式に指定されたユーザーの可用性ステータス。これは、RFC 6121 [RFC6121]のセクション4.7.2.1で定義されている同じ名前の存在要素に似ていることに注意してください。このアイテムの値は、次のいずれかです。

away: The user is temporarily away.

離れて：ユーザーは一時的に離れています。

chat: The user is online and actively interested in chatting.

チャット：ユーザーはオンラインで、チャットに積極的に興味を持っています。

dnd: Do Not Disturb; the user does not wish to be disturbed now.

DND：邪魔しないでください。ユーザーは今、邪魔されることを望んでいません。

offline: The user is offline.

オフライン：ユーザーはオフラインです。

xa: The user is away for an extended period (xa = "eXtended Away").

XA：ユーザーは長期間離れています（xa = "extended Away"）。

unknown: The correct presence value could not be determined.

不明：正しい存在値を決定できませんでした。

status: A human-readable description of the user's availability status, in natural language. There is no formal definition for the values this item may take. It is free-form, and may be in any language. Direct comparisons against the value of this field are unlikely to be useful; rather, it is provided to enable extraction of the value into a variable [RFC5229] for use elsewhere (see example 3 in Section 3). Note that this is similar to the presence element with the same name that's defined in Section 4.7.2.2 of RFC 6121 [RFC6121], and to the <note> element defined in section 4.1.6 of PIDF [RFC3863].

ステータス：自然言語におけるユーザーの可用性ステータスの人間が読みやすい説明。このアイテムがとるかもしれない価値について正式な定義はありません。それは自由形であり、どんな言語でもあります。このフィールドの価値との直接的な比較は、有用ではありません。むしろ、他の場所で使用するために値を変数[RFC5229]に抽出できるように提供されます（セクション3の例3を参照）。これは、RFC 6121 [RFC6121]のセクション4.7.2.2で定義されている同じ名前の存在要素と、PIDF [RFC3863]のセクション4.1.6で定義されている<nte>要素に類似していることに注意してください。

Because this is a free-form value that might be created directly by a user, no value, including "unknown", can have any special meaning. If the Sieve processor is unable to determine the value of this item, it might be best to leave it as an empty string. In any case, it is not meant for machine-readable processing, beyond possible XML interpretation.

これはユーザーが直接作成できるフリーフォーム値であるため、「不明」を含む値は特別な意味を持つことはできません。Sieveプロセッサがこのアイテムの値を決定できない場合、空の文字列として残すのが最善かもしれません。いずれにせよ、それはXML解釈の可能性を超えて、機械読み取り可能な処理を意図したものではありません。

There is no capability string associated with this extension, but this requires support for "enotify" [RFC5435]. If the implementation does not support the item being tested (that is, the specified notification-capability item is not known to the Sieve interpreter), RFC 5435 already specifies that the test fail without an error.

この拡張機能に関連する能力文字列はありませんが、これには「enotify」[RFC5435]のサポートが必要です。実装がテストされているアイテムをサポートしていない場合（つまり、指定された通知能力項目がふるいインタープリターにはわからない）、RFC 5435は、テストがエラーなしで失敗することをすでに指定しています。

Although this feature was conceived to assist in notifications, and the test requires support of the Sieve Notify feature, it is only a condition test, and any Sieve action can appear inside it. There are no Sieve actions that conflict with this extension.

この機能は通知を支援するために考案され、テストではふるい通知機能のサポートが必要ですが、それは条件テストのみであり、シーブアクションはその内部に表示される可能性があります。この拡張機能と矛盾するふるい行動はありません。

3. Examples

3. 例

1. This example will send a notification only if the recipient is not "busy". If the test for "busy" is not supported, this example will not send a notification.

1. この例は、受信者が「忙しくない」場合にのみ通知を送信します。「ビジー」のテストがサポートされていない場合、この例は通知を送信しません。

require ["enotify"];

["enotify"]を必要とします。

   if notify_method_capability "xmpp:tim@example.com" "busy" "no"
     {
       notify :message "You got mail"
           "xmpp:tim@example.com?message;subject=SIEVE";
     }

2. This example will send a notification only if the recipient is not "busy". If the test for "busy" is not supported, this example will send a notification.

2. この例は、受信者が「忙しくない」場合にのみ通知を送信します。「ビジー」のテストがサポートされていない場合、この例は通知を送信します。

require ["enotify"];

["enotify"]を必要とします。

   if not notify_method_capability "xmpp:tim@example.com" "busy" "yes"
     {
       notify :message "You got mail"
           "xmpp:tim@example.com?message;subject=SIEVE";
     }

3. This example uses the vacation extension [RFC5230] to generate an auto-reply [RFC6133] if the sender is in the recipient's address book [RFC6134] and the recipient's presence shows "extended away". The variables extension [RFC5229] is used to extract the value of the recipient's presence status message, which will be used in the response to the sender. If the test for "show" is not supported, this example will not send an auto-reply.

3. この例では、バケーションエクステンション[RFC5230]を使用して、送信者が受信者のアドレス帳[RFC6134]に属し、受信者の存在が「延長」を示している場合、自動対応[RFC6133]を生成します。変数拡張[RFC5229]は、送信者への応答で使用される受信者の存在ステータスメッセージの値を抽出するために使用されます。「show」のテストがサポートされていない場合、この例では自動応答は送信されません。

require ["extlists", "vacation", "enotify", "variables"];

["extlists"、 "vacation"、 "enotify"、 "変数"を要求する];

   if allof (
       envelope :list "from" ":addrbook:default",
       notify_method_capability "xmpp:myjid@example.com" "show" "xa"
     ) {
       # :matches "*" is used here to extract the value
       if notify_method_capability :matches
           "xmpp:myjid@example.com" "status" "*" {
         set "resp_msg" "${1}";
       } else {
         set "resp_msg" "I'm away from email for a while."
       }
       vacation :handle "ext-away" "${resp_msg}";
     }

4. Security Considerations

4. セキュリティに関する考慮事項

Security considerations for Sieve [RFC5228] and the Notify extension [RFC5435] apply equally here. In addition, implementations MUST ensure that users cannot create scripts that access the presence information of others without the proper access controls.

Sieve [RFC5228]およびNotify Extension [RFC5435]のセキュリティ上の考慮事項は、ここでも同様に適用されます。さらに、実装は、適切なアクセス制御なしで他の人の存在情報にアクセスするスクリプトを作成できないようにする必要があります。

In some situations, scripts may act on some of the recipient's presence information that the sender of the triggering message is not allowed to see. This can be a benefit to the recipient in many cases, but it can also present an opportunity for a sender to use messages to probe the recipient's presence (if, for example, messages sometimes result in auto-replies, and sometimes do not). Script authors should take care in considering this aspect of presence-triggered actions.

状況によっては、スクリプトは、トリガーメッセージの送信者が表示されないという受信者の存在情報の一部に作用する場合があります。これは、多くの場合、受信者にとって利益になる可能性がありますが、送信者がメッセージを使用して受信者の存在をプローブする機会を提供することもあります（たとえば、メッセージが自動レプリーを作成する場合があり、場合によってはそうでない場合）。スクリプトの著者は、存在する存在感のあるアクションのこの側面を考慮する際に注意する必要があります。

It's possible for a large number of messages to arrive at or around the same time and be processed by Sieve scripts that all test presence. If many of the users share the same presence server, such a burst could put an unexpectedly heavy load on the presence server. Implementations might consider providing options for rate limiting, or for caching presence tests for periods of time, even across Sieve script instances. When caching presence tests, the server must be careful not to violate access controls that the presence server might have. Thus, cached results MUST NOT be used outside the context in which they were retrieved. If, for example, a script running on behalf of Adam requests presence information for Barbara, that information MAY be cached for a future script running on behalf of Adam, but MUST NOT be used to satisfy the same query in a script running on behalf of Cindy -- because the presence server will have to decide whether Cindy has access to that information.

多数のメッセージが同時に到着するか、それ以外に到着し、すべてのテストの存在感をシーブスクリプトによって処理することが可能です。ユーザーの多くが同じプレゼンスサーバーを共有している場合、そのようなバーストは、プレゼンスサーバーに予想外に重い負荷をかける可能性があります。実装では、レート制限、またはシーブスクリプトインスタンス全体でさえ、期間にわたってプレゼンステストをキャッシュするオプションを提供することを検討する場合があります。プレゼンステストをキャッシュするとき、サーバーは、プレゼンスサーバーが持っている可能性のあるアクセス制御に違反しないように注意する必要があります。したがって、キャッシュされた結果は、それらが取得されたコンテキストの外で使用してはなりません。たとえば、Adamを代表して実行されているスクリプトがBarbaraの存在情報を要求する場合、その情報はAdamに代わって実行されている将来のスクリプトに対してキャッシュされる可能性がありますが、に代わって実行されているスクリプトで同じクエリを満たすために使用してはなりません。Cindy-プレゼンスサーバーは、Cindyがその情報にアクセスできるかどうかを決定する必要があるためです。

5. IANA Considerations

5. IANAの考慮事項

This registers each presence item as a notification-capability parameter. Future extensions that add new presence items should register those items similarly, using the instructions in Section 9.3 of RFC 5435 [RFC5435].

これにより、各存在項目が通知能力パラメーターとして登録されます。新しい存在アイテムを追加する将来の拡張機能は、RFC 5435 [RFC5435]のセクション9.3の指示を使用して、これらのアイテムを同様に登録する必要があります。

To: iana@iana.org Subject: Registration of a new notification-capability parameter Capability name: busy Description: An indication of whether the user is considered "busy" now (the value "yes") or not (the value "no"). The meaning of "busy" is left to the implementation, and may be a state that's synthesized from other information. Syntax: Has one of the values "yes", "no", or "unknown". The value MUST be in lower case.

宛先：iana@iana.org件名：新しい通知の能力パラメーター機能の登録機能名：忙しい説明：ユーザーが「忙しい」と見なされているかどうかを示す（値「はい」）かどうか（値「いいえ」）。「ビジー」の意味は実装に委ねられており、他の情報から合成された状態である可能性があります。構文：「はい」、「いいえ」、または「不明」の値の1つがあります。値は小文字でなければなりません。

   Permanent and readily available reference(s):  RFC 6132
   Contact information:  The Sieve discussion list, <sieve@ietf.org>

   To:  iana@iana.org
   Subject:  Registration of a new notification-capability parameter
   Capability name:  show
   Description:  The availability status of the user.  This is similar
        to the presence element with the same name that's defined in
        Section 4.7.2.1 of RFC 6121.
   Syntax:  Has one of the values "away", "chat", "dnd", "offline",
        "xa", or "unknown".  The value MUST be in lower case.
   Permanent and readily available reference(s):  RFC 6132
   Contact information:  The Sieve discussion list, <sieve@ietf.org>

To: iana@iana.org Subject: Registration of a new notification-capability parameter Capability name: status Description: A human-readable description of the user's availability status. This is similar to the presence element with the same name that's defined in Section 4.7.2.2 of RFC 6121. Syntax: There is no formal definition for the values this item may take. It is free-form and may be in any language, and is meant for human consumption. Permanent and readily available reference(s): RFC 6132 Contact information: The Sieve discussion list, <sieve@ietf.org>

宛先：iana@iana.org件名：新しい通知の能力パラメーター機能の登録名：ステータス説明：ユーザーの可用性ステータスの人間読み取り可能な説明。これは、RFC 6121のセクション4.7.2.2で定義されている同じ名前の存在要素に似ています。構文：このアイテムがとる値に正式な定義はありません。それは自由形であり、あらゆる言語である可能性があり、人間の消費を対象としています。恒久的で容易に利用できるリファレンス：RFC 6132連絡先情報：シーブディスカッションリスト、<sieve@ietf.org>

6. Acknowledgments

6. 謝辞

The authors thank Alexey Melnikov for significant early feedback and suggestions.

著者は、重要な早期フィードバックと提案をしてくれたAlexey Melnikovに感謝します。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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月。

[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月。

[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.

[RFC6121] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：インスタントメッセージングと存在」、RFC 6121、2011年3月。

7.2. Informative References

7.2. 参考引用

[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.

[RFC3863] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。

[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.

[RFC4480] Schulzrinne、H.、Gurbani、V.、Kyzivat、P。、およびJ. Rosenberg、「RPID：Rich Expentionが存在情報データ形式（PIDF）（PIDF）の拡張」、RFC 4480、2006年7月。

[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.

[RFC5229] Homme、K。、「Sieve Emailフィルタリング：変数拡張」、RFC 5229、2008年1月。

[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.

[RFC5230] Showalter、T。and N. Freed、「Sieve Emailフィルタリング：休暇拡張」、RFC 5230、2008年1月。

[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.

[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「Geopriv存在情報データ形式の場所オブジェクト（PIDF-LO）使用法の明確化、考慮事項、および推奨事項」、RFC 5491、2009年3月。

[RFC6133] George, R., Leiba, B., and A. Melnikov, "Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality", RFC 6134, July 2011.

[RFC6133] George、R.、Leiba、B。、およびA. Melnikov、「Sieve Emailフィルタリング：自動応答機能による存在情報の使用」、RFC 6134、2011年7月。

[RFC6134] Melnikov, A. and B. Leiba, "Sieve Extension: Externally Stored Lists", RFC 6134, July 2011.

[RFC6134] Melnikov、A。およびB. Leiba、「Sieve Extension：外部保存リスト」、RFC 6134、2011年7月。

Authors' Addresses

著者のアドレス

Robins George Huawei Technologies Bangalore, Karnataka 560071 India

ロビンズジョージホーウェイテクノロジーズバンガロール、カルナタカ560071インド

   Phone: +91-080-41117676
   EMail: robinsgv@gmail.com

Barry Leiba Huawei Technologies

   Phone: +1 646 827 0648
   EMail: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/