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.

これは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.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6132で取得することができます。

Copyright Notice

著作権表示

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2011 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.  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機能)を定義し、および(RFC 5435のセクション5に記載された「オンライン」通知機能)の存在のための1つのテストを定義します。この拡張は、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].

大文字のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである"、 "MAY"、および "オプション" でこのドキュメントは[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).

ふるい[RFC5228]プレゼンス情報をテストするために、拡張[RFC5435]を通知で定義されるように、この拡張は、notify_method_capability試験を使用します。ふるいのイベントは、ユーザーのために(メールが届い)が発生した場合、そのユーザーの代わりに実行されているSieveスクリプトは、(「通知のuri」パラメータで)、ユーザーのプレゼンス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にリッチプレゼンス拡張[RFC4480]、およびGEOPRIVプレゼンス情報データフォーマット位置オブジェクト(PIDF-LO)[RFC5491]:プレゼンスデータおよびフォーマットのために有用な情報の参照は、プレゼンス情報データフォーマット(PIDF)[RFC3863]、RPIDが挙げられます。

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: 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 =「アウェイ拡張」)のために離れています。

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のセクション4.7.2.2 [RFC6121]で定義されたのと同じ名前のプレゼンス要素に類似していることに注意してください、そしてPIDFのセクション4.1.6で定義された<注意>要素に[RFC3863]。

            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.
        

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.

この機能は、通知を支援するために考案され、テストがふるい通知機能のサポートを必要としましたが、それが唯一の条件のテストで、かつ任意のSieveアクションは、その中に表示されます。この拡張機能とはふるいアクション競合はありません。

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"; }

もしnotify_method_capability "XMPP:tim@example.com" "忙しい" "いいえ" {通知:メッセージは、 "あなたはメールを得ました" "XMPP:?tim@example.comメッセージ、件名= 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"; }

そうでない場合notify_method_capability "XMPP:tim@example.com" "忙しい" "はい" {通知:メッセージは、 "あなたはメールを得ました" "XMPP:?tim@example.comメッセージ、件名= 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.この例では、送信者が受信者のアドレス帳[RFC6134]であると受信者の存在が「離れて延長」を示す場合には自動返信[RFC6133]を生成するために休暇を延長[RFC5230]を使用しています。変数拡張[RFC5229]は、送信者への応答に使用される受信者のプレゼンスステータスメッセージ、の値を抽出するために使用されます。 「ショー」のためのテストがサポートされていない場合、この例では、自動返信を送信しません。

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

[ "extlists"、 "休暇"、 "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.

ふるい[RFC5228]と通知拡張[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.

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

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.

To:iana@iana.org件名:新しい通知機能パラメータの機能名の登録:忙しい説明:ユーザーが「ビジー」になりました(値「はい」)かない(値「なし」と見なされているかどうかの表示)。 「忙しい」の意味は、実装に残され、その他の情報から合成されています状態かもしれません。構文:「はい」、「いいえ」、または「不明」のいずれかの値になります。値は小文字でなければなりません。

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

恒久的かつ容易に利用可能な基準(S):RFC 6132連絡先情報:ふるいディスカッションリスト、<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件名:show説明:ユーザーの可用性ステータス新しい通知機能パラメータ機能名の登録。 「離れ」のいずれかの値になり、「チャット」、「DND」、「オフライン」、「XA」、または:これはRFCのセクション4.7.2.1 6121構文で定義されているのと同じ名前のプレゼンス要素に似ています"未知の"。値は小文字でなければなりません。恒久的かつ容易に利用可能な基準(S):RFC 6132連絡先情報:ふるいディスカッションリスト、<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>

To:iana@iana.org件名:新しい通知機能パラメータの機能名の登録:状況説明:ユーザーの可用性ステータスの人間が読める形式の説明。これは、RFC 6121の構文のセクション4.7.2.2で定義されたのと同じ名前のプレゼンス要素に似ています。この項目が取り得る値のための正式な定義はありません。これは、自由な形式で、任意の言語であってもよく、人間の消費のためのものです。恒久的かつ容易に利用可能な基準(S):RFC 6132連絡先情報:ふるいディスカッションリスト、<sieve@ietf.org>

6. Acknowledgments
6.謝辞

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

著者は、重要な早期のフィードバックや提案のためのアレクセイ・メルニコフに感謝します。

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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

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

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

[RFC6121]サンアンドレ、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]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット(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.ローゼンバーグ、 "RPID:プレゼンス情報データフォーマット(PIDF)にリッチプレゼンスの拡張"、RFC 4480、2006年7月。

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

[RFC5229]オム、K.、 "ふるいメールフィルタリング:変数の拡張"、RFC 5229、2008年1月。

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

[RFC5230]ショーウォルター監督、T.およびN.フリード、 "ふるいメールフィルタリング:休暇延長"、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]ウィンターボトム、J.、トムソン、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]ジョージ、R.、Leiba、B.、およびA.メルニコフ、 "ふるいメールフィルタリング:自動レスポンダの機能とプレゼンス情報の使用"、RFC 6134、2011年7月。

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

[RFC6134]メルニコフ、A.及びB. Leiba、 "ふるい拡張:外部に格納されたリスト"、RFC 6134、2011年7月。

Authors' Addresses

著者のアドレス

Robins George Huawei Technologies Bangalore, Karnataka 560071 India

ロビンスジョージ・華為技術カルナータカ州バンガロール560071インド

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

電話:+ 91-080-41117676電子メール:robinsgv@gmail.com

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/