Network Working Group                                         R. Gellens
Request for Comments: 5423                                 QUALCOMM Inc.
Category: Standards Track                                      C. Newman
                                                        Sun Microsystems
                                                              March 2009
        
                     Internet Message Store Events
        

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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書では、BCP 78と、この文書(http://trustee.ietf.org/license-info)の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

Abstract

抽象

One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to-client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.

既存のインターネットメールとメッセージング標準規格で欠けている機能の一つは、メッセージストアのイベントに関連するイベント通知サーバー・サーバーへとサーバーからクライアントのための施設です。インターネットメールのスコープは、相互運用の必要性、より多様な(例えばボイスメールなど)のメディアと(携帯電話など)のデバイスをサポートし、(そのようなWebポータルや法令遵守システムなど)の他のサービスとの豊かな相互作用を提供するために拡大するにつれて通知システムが増加します。この文書では、このようなシステムの関心実世界の消費者イベントの種類を列挙しようとします。

This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP.

この文書では、管理システムやエンドユーザーへの通知など、いくつかの場合に便利であるイベントとイベント・パラメータを、説明しています。これは、IMAPなどのメッセージアクセス機能の代替として意図されていません。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Event Model  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Event Types  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Message Addition and Deletion  . . . . . . . . . . . . . .  5
     4.2.  Message Flags  . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Access Accounting  . . . . . . . . . . . . . . . . . . . .  8
     4.4.  Mailbox Management . . . . . . . . . . . . . . . . . . . .  8
   5.  Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Future Extensions . . . . . . . . . . . . . . . . . . 17
        
1. Introduction
1. はじめに

A message store is used to organize Internet Messages [RFC5322] into one or more mailboxes (possibly hierarchical), annotate them in various ways, and provide access to these messages and associated metadata. Three different standards-based protocols have been widely deployed to remotely access a message store. The Post Office Protocol (POP) [RFC1939] provides simple download-and-delete access to a single mail drop (which is a subset of the functionality typically associated with a message store). The Internet Message Access Protocol (IMAP) [RFC3501] provides an extensible feature-rich model for online, offline, and disconnected access to a message store with minimal constraints on any associated "fat-client" user interface. Finally, mail access applications built on top of the Hypertext Transfer Protocol (HTTP) [RFC2616] that run in standards-based web browsers provide a third standards-based access mechanism for online-only access.

メッセージストアは、1つまたは複数のメールボックス(恐らく階層)にインターネットメッセージ[RFC5322]を整理する様々な方法でそれらに注釈を付け、これらのメッセージと関連するメタデータへのアクセスを提供するために使用されます。三つの異なる標準ベースのプロトコルが広く、遠隔メッセージストアにアクセスするために配備されています。ポストオフィスプロトコル(POP)[RFC1939](典型的には、メッセージストアに関連付けられた機能のサブセットである)は、単一のメールドロップに簡単なダウンロード・アンド・削除アクセスを提供します。インターネットメッセージアクセスプロトコル(IMAP)[RFC3501]は、オンライン、オフライン、および関連する「ファットクライアント」ユーザーインターフェース上の最小限の制約で、メッセージストアへの非接続アクセスするための拡張機能豊富なモデルを提供します。最後に、標準ベースのWebブラウザで実行するハイパーテキスト転送プロトコル(HTTP)の上に構築されたメールアクセスアプリケーション[RFC2616]は、オンラインのみのアクセスのための第三の標準ベースのアクセスメカニズムを提供します。

While simple and/or ad-hoc mechanisms for notifications have sufficed to some degree in the past (e.g., "Simple New Mail Notification" [RFC4146], "IMAP4 IDLE Command" [RFC2177]), as the scope and importance of message stores expand, the demand for a more complete store notification system increases. Some of the driving forces behind this demand include:

通知のためのシンプルかつ/またはアドホックメカニズムは過去にある程度足りているが(例えば、「シンプル新着メールの通知」[RFC4146]、「IMAP4 IDLEコマンド」[RFC2177])、メッセージストアの範囲と重要性、より完全な店舗通知システムの需要が増加を展開します。この需要の原動力の一部を以下に示します。

o Mobile devices with intermittent network connectivity that have "new mail" or "message count" indicators.

「新規メール」または「メッセージ数」の指標を持って断続的にネットワーク接続したモバイルデバイスO。

o Unified messaging systems that include both Internet and voice mail require support for a message-waiting indicator on phones.

Oインターネットやボイスメールの両方が含まれるユニファイドメッセージングシステムは、電話のメッセージウェイティングインジケータのためのサポートを必要とします。

o Interaction with systems for event-based or utility-computing billing.

Oイベントベースまたはユーティリティ・コンピューティングの課金のためのシステムとの相互作用。

o Simplification of the process of passing message store events to non-Internet notification systems.

O非インターネット通知システムにメッセージストアイベントを渡す工程の簡略化。

o A calendar system may wish to subscribe to MessageNew notifications in order to support iMIP [RFC2447].

OカレンダーシステムはiMIPの[RFC2447]をサポートするためにMessageNew通知に加入することを望むかもしれません。

o Some jurisdictions have laws or regulations for information protection and auditing that require interoperable protocols between message stores built by messaging experts and compliance auditing systems built by compliance experts.

Oいくつかの法域では、メッセージングの専門家によって建てられたメッセージストアおよびコンプライアンスの専門家によって建てられたコンプライアンス監査システム間の相互運用可能なプロトコルを必要とする情報の保護と監査のための法律や規制を持っています。

Vendors who have deployed proprietary notification systems for their Internet message stores have seen significant demand to provide notifications for more and more events. As a first step towards building a notification system, this document attempts to enumerate the core events that real-world customers demand.

彼らのインターネットメッセージを格納するために独自の通知システムを展開しているベンダーは、より多くのイベントの通知を提供するための重要な需要を見てきました。通知システムの構築に向けた最初のステップとして、この文書は、実世界の顧客が要求するコアイベントを列挙しようとします。

This document includes those events that can be generated by the use of IMAP4rev1 [RFC3501] and some existing extensions. As new IMAP extensions are defined, or additional event types or parameters need to be added, the set specified here can be extended by means of an IANA registry with update requirements, as specified in Section 6.

この文書では、IMAP4rev1の[RFC3501]といくつかの既存の拡張機能を使用することによって生成することができ、それらのイベントを含んでいます。新しいIMAP拡張が定義され、または追加のイベントタイプまたはパラメータを追加する必要があるとして、第6節で指定されているように、ここで指定されたセットは、更新要件を持つIANAレジストリによって拡張することができます。

1.1. Conventions Used in This Document
1.1. このドキュメントの表記規則

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]. When these words appear in lower-case or with initial capital letters, they are not RFC 2119 key words.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載されているように解釈されます。これらの単語は小文字でまたは初期大文字で表示されたとき、彼らは、RFC 2119のキーワードではありません。

2. Terminology
2.用語

The following terminology is used in this document:

以下の用語は、本書で使用されます。

mailbox A container for Internet messages and/or child mailboxes. A mailbox may or may not permit delivery of new messages via a mail delivery agent.

インターネットメッセージおよび/または子メールボックスのコンテナをメールボックス。メールボックスは、メール配送エージェント経由で新しいメッセージの配信を許可しない場合があります。

mailbox identifier A mailbox identifier provides sufficient information to identify a specific mailbox on a specific server instance. An IMAP URL can be a mailbox identifier.

メールボックスは、メールボックス識別子は、特定のサーバーインスタンス上の特定のメールボックスを識別するのに十分な情報を提供する識別子。 IMAPのURLは、メールボックス識別子することができます。

message access protocols Protocols that provide clients (e.g., a mail user agent or web browser) with access to the message store, including but not limited to IMAP, POP, and HTTP.

クライアントを提供するメッセージ・アクセス・プロトコルのプロトコル(例えば、メールユーザエージェント、またはウェブブラウザ)を含むが、IMAP、POP、およびHTTPに限定されるものではなく、メッセージストアへのアクセスを有します。

message context As defined in [RFC3458].

[RFC3458]で定義されるようにメッセージコンテキスト。

UIDVALIDITY As defined in IMAP4rev1 [RFC3501]. UIDVALIDITY is critical to the correct operation of a caching mail client. When it changes, the client MUST flush its cache. It's particularly important to include UIDVALIDITY with event notifications related to message addition or removal in order to keep the message data correctly synchronized.

IMAP4rev1の[RFC3501]で定義されるようにUIDVALIDITY。 UIDVALIDITYは、キャッシングのメールクライアントが正しく動作するために重要です。それが変化した場合、クライアントはそのキャッシュをフラッシュする必要があります。それは、正しく同期メッセージデータを保持するために、メッセージの追加または削除に関連するイベント通知とUIDVALIDITYを含めることが特に重要です。

3. Event Model
3.イベントモデル

The events that are generated by a message store depend to some degree on the model used to represent a message store. The model the IETF has for a message store is implicit from IMAP4rev1 and extensions, so that model is assumed by this document.

メッセージストアによって生成されたイベントは、メッセージストアを表すために使用されるモデルにある程度依存します。モデルがこのドキュメントによって想定されるようにIETFがメッセージストアに有するモデルは、のIMAP4rev1と拡張から暗黙的です。

A message store event typically has an associated mailbox name and usually has an associated user name (or authorization identity if using the terminology from "Simple Authentication and Security Layer" (SASL) [RFC4422]). Events referring to a specific message can use an IMAP URL [RFC5092] to do so. Events referring to a set of messages can use an IMAP URL to the mailbox plus an IMAP UID (Unique Identifier) set.

メッセージストアイベントは、一般的に関連付けられているメールボックスの名前があり、通常は関連付けられたユーザー名(または認可ID「簡易認証セキュリティー層」からの用語を使用している場合(SASL)[RFC4422])を持っています。特定のメッセージを参照するイベントがそうするようにIMAPのURL [RFC5092]を使用することができます。メッセージのセットを参照するイベントは、メールボックスプラスIMAP UID(一意識別子)のセットにIMAPのURLを使用することができます。

Each notification has a type and parameters. The type determines the type of event, while the parameters supply information about the context of the event that may be used to adjust subscription preferences or may simply supply data associated with the event. The types and parameter names in this document are restricted to US-ASCII printable characters, so these events can be easily mapped to an arbitrary notification system. However, this document assumes that arbitrary parameter values (including large and multi-line values) can be encoded with the notification system. Systems which lack that feature could only implement a subset of these events.

各通知は、タイプとパラメータがあります。パラメータは、サブスクリプション設定を調整するために使用され得るか、または単にイベントに関連するデータを供給することができるイベントのコンテキストに関する情報を提供しながらタイプは、イベントのタイプを決定します。この文書に記載されているタイプとパラメータ名はUS-ASCII印刷可能文字に制限されているため、これらのイベントは、簡単に任意の通知システムにマッピングすることができます。しかし、この文書は(大規模マルチライン値を含む)の任意のパラメータ値が通知システムで符号化することができることを前提としています。その機能が不足しているシステムでは、これらのイベントのサブセットを実装することができます。

This document does not indicate which event parameters are mandatory or optional. That is done in documents that specify specific message formats or bindings to a notification system.

この文書では、必須またはオプションであるイベントのパラメータを示すものではありません。これは、通知システムに特定のメッセージ形式またはバインディングを指定した文書で行われます。

For scalability reasons, some degree of filtering at event generation is necessary. At the very least, the ability to turn on and off groups of related events and to suppress inclusion of large parameters (such as messageContent) is needed. A sophisticated publish/subscribe notification system may be able to propagate cumulative subscription information to the publisher.

スケーラビリティの理由から、イベント生成でのフィルタリングのいくつかの程度が必要です。少なくとも、関連イベントのグループにし、オフにすると(例えばmessageContentなど)大きなパラメータの混入を抑制する能力が必要です。洗練されたパブリッシュ/サブスクライブ通知システムは、パブリッシャに累積加入者情報を伝播することができるかもしれません。

Some of these events might be logically collapsed into a single event type with a required parameter to distinguish between the cases (e.g., QuotaExceed and QuotaWithin). However, until such time that an event subscription model is formulated, it's not practical to make such decisions. We thus note only the fact that some of these events may be viewed as a single event type.

これらのイベントの一部は、論理的な場合(例えば、QuotaExceedとQuotaWithin)を区別するために必要なパラメータを使用して単一のイベント型に折りたたまれるかもしれません。しかし、イベントサブスクリプションモデルが定式化されるような時間まで、そのような決定を下すために実用的ではありません。そこで我々は、これらのイベントのいくつかは、単一のイベントタイプとして見ることができるという事実のみに注意してください。

4. Event Types
4.イベントタイプ

This section discusses the different types of events useful in a message store event notification system. The intention is to document the events sufficient to cover an overwhelming majority of known use cases while leaving less common event types for the future. This section mentions parameters that are important or specific to the events described here. Event parameters likely to be included in most or all notifications are discussed in the next section.

このセクションでは、メッセージストアイベント通知システムに有用なイベントの種類を説明します。その意図は、将来のために、あまり一般的イベントタイプを残しながら、知られているユースケースの圧倒的多数をカバーするのに十分なイベントを文書化することです。このセクションでは、ここで説明したイベントに重要または特定のパラメータに言及しています。ほとんどまたはすべての通知に含まれる可能性が高いイベントパラメータは、次のセクションで説明されています。

4.1. Message Addition and Deletion
4.1. メッセージの追加と削除

This section includes events related to message addition and deletion.

このセクションでは、メッセージの追加と削除に関連するイベントが含まれています。

MessageAppend A message was appended or concatenated to a mailbox by a message access client. For the most part, this is identical to the MessageNew event type except that the SMTP envelope information is not included as a parameter, but information about which protocol triggered the event MAY be included. See the MessageNew event for more information.

MessageAppendメッセージは、メッセージアクセスクライアントでメールボックスに追加または連結されました。ほとんどの部分については、これは、SMTPエンベロープ情報がパラメータとして含まれていないことを除いてMessageNewイベントタイプと同じですが、プロトコルはイベントをトリガしたかについての情報が含まれるかもしれません。詳細については、MessageNewイベントを参照してください。

MessageExpire One or more messages were expired from a mailbox due to server expiration policy and are no longer accessible by the end user.

MESSAGEEXPIRE 1つ以上のメッセージは、サーバーの有効期限ポリシーによるメールボックスから期限切れ、もはやエンドユーザがアクセス可能ですました。

The parameters include a mailbox identifier that MUST include UIDVALIDITY and a UID set that describes the messages.

パラメータは、UIDVALIDITYとメッセージについて説明UIDセットを含まなければならないメールボックスの識別子が含まれます。

Information about which server expiration policy was applied may be included in the future.

サーバーの有効期限ポリシーが適用されたかについての情報は、将来的には含まれていてもよいです。

MessageExpunge One or more messages were expunged from a mailbox by an IMAP CLOSE/EXPUNGE, POP3 DELE+QUIT, HTTP, or equivalent client action and are no longer accessible by the end user.

1つの以上のメッセージは、IMAP CLOSE / EXPUNGE、POP3のDELE + QUIT、HTTP、または同等のクライアントアクションによってメールボックスから消去され、もはやエンドユーザーがアクセスしているたMessageExpunge。

The parameters include a mailbox identifier that MUST include UIDVALIDITY, a UID set, and MAY also indicate which access protocol triggered the event.

パラメータはUIDVALIDITY、UIDのセットを含まなければなりません、そして、イベントをトリガしたプロトコルにアクセスするかを示すMAYメールボックス識別子を含みます。

MessageNew A new message was received into a mailbox via a message delivery agent.

MessageNew新しいメッセージは、メッセージ配送エージェント経由でメールボックスに受信しました。

The parameters include a message identifier that, for IMAP-accessible message stores, MUST include UIDVALIDITY and a UID. The parameters MAY also include an SMTP envelope and other arbitrary message and mailbox metadata. In some cases, the entire new message itself may be included. The set of parameters SHOULD be adjustable to the client's preference, with limits set by server policy. An interesting policy, for example, would be to include messages up to 2K in size with the notification, but to include a URLAUTH [RFC4467] reference for larger messages.

パラメータは、IMAPアクセス可能なメッセージストアのため、UIDVALIDITYとUIDを含まなければなりません、メッセージの識別子を含みます。パラメータはまた、SMTPエンベロープや他の任意のメッセージやメールボックスのメタデータを含むことができます。いくつかのケースでは、全体の新しいメッセージ自体は含まれていてもよいです。パラメータのセットは、サーバのポリシーで設定された制限で、クライアントの好みに調整可能であるべきです。興味深いポリシーは、例えば、通知にサイズが2Kにメッセージを含めることであろうが、より大きなメッセージのURLAUTH [RFC4467]参照を含むこと。

QuotaExceed An operation failed (typically MessageNew) because the user's mailbox exceeded one of the quotas (e.g., disk quota, message quota, quota by message context, etc.). The parameters SHOULD include at least the relevant user and quota and, optionally, the mailbox. Quota usage SHOULD be included if possible. Parameters needed to extend this to support quota by context are not presently described in this document but could be added in the future.

ユーザのメールボックスがクォータのいずれかを超えたため、操作が(典型的にMessageNew)を失敗QuotaExceed(例えば、ディスククォータ、メッセージクォータ、メッセージコンテキストによってクォータなど)。パラメータは、少なくとも当該ユーザとクォータと、必要に応じて、メールボックスを含むべきです。クォータの使用率は、可能な場合は含まれるべきです。文脈によってクォータをサポートするために、これを拡張するために必要なパラメータは、現在、このドキュメントに記載されていないが、将来的に追加することができます。

QuotaWithin An operation occurred (typically MessageExpunge or MessageExpire) that reduced the user's quota usage under the limit.

QuotaWithinは動作限界の下でユーザのクォータの使用量を減少させた(典型的にはMessageExpunge又はMESSAGEEXPIRE)を生じました。

QuotaChange The user's quota was changed.

QuotaChangeユーザーの割り当てが変更されました。

4.2. Message Flags
4.2. メッセージフラグ

This section includes events related to changes in message flags.

このセクションでは、メッセージフラグの変化に関連するイベントが含まれています。

MessageRead One or more messages in the mailbox were marked as read or seen by a user. Note that POP has no concept of read or seen messages, so these events are only generated by IMAP or HTTP clients (or equivalent).

読み取りまたはユーザーが見られるように、メールボックス内の1件の以上のメッセージが記されたMessageRead。そのPOPに注意して読んだり、見られたメッセージの概念がないので、これらのイベントは、唯一のIMAPまたはHTTPクライアント(または同等の)によって生成されます。

The parameters include a mailbox identifier and a set of message UIDs.

パラメータは、メールボックス識別子とメッセージのUIDのセットを含みます。

MessageTrash One or more messages were marked for future deletion by the user but are still accessible over the protocol (the user's client may or may not make these messages accessible through its user interface).

1つの以上のメッセージは、ユーザによる将来の削除のためにマークされますが、まだプロトコル(ユーザのクライアントが、またはそのユーザーインタフェースを介して、これらのメッセージにアクセスできるようにしない場合があり)を介してアクセスされているたMessageTrash。

The parameters include a mailbox identifier and a set of message UIDs.

パラメータは、メールボックス識別子とメッセージのUIDのセットを含みます。

FlagsSet One or more messages in the mailbox had one or more IMAP flags or keywords set.

メールボックス内のFlagsSet 1つ以上のメッセージは、設定された1つ以上のIMAPフラグやキーワードを持っていました。

The parameters include a list of IMAP flag or keyword names that were set, a mailbox identifier, and the set of UIDs of affected messages. The flagNames MUST NOT include \Recent. For compatibility with simpler clients, it SHOULD be configurable whether setting the \Seen or \Deleted flags results in this event or the simpler MessageRead/MessageTrash events. By default, the simpler message forms SHOULD be used for MessageRead and MessageTrash.

パラメータは、IMAPフラグのリストまたは設定されたキーワード名、メールボックスの識別子、および影響を受けたメッセージのUIDのセットが含まれています。 flagNamesは\最近のを含んではいけません。シンプルなクライアントとの互換性のために、見\または\削除されたフラグこのイベントでの結果または単純MessageRead / MessageTrashイベントを設定するかどうかを設定可能であるべきです。デフォルトでは、単純なメッセージフォームはMessageReadとMessageTrashのために使用されるべきです。

FlagsClear One or more messages in the mailbox had one or more IMAP flags or keywords cleared.

メールボックス内のFlagsClear 1つ以上のメッセージはクリア一つ以上のIMAPフラグやキーワードを持っていました。

The parameters include a list of IMAP flag or keyword names that were cleared, a mailbox identifier, and the set of UIDs of affected messages. The flagNames parameter MUST NOT include \Recent.

パラメータは、IMAPフラグまたはクリアされたキーワード名のリスト、メールボックスの識別子、および影響を受けたメッセージのUIDのセットが含まれています。 flagNamesパラメータは、\最近のを含んではいけません。

4.3. Access Accounting
4.3. アクセス会計

This section lists events related to message store access accounting.

このセクションでは、メッセージストアアクセス会計に関連するイベントを一覧表示します。

Login A user has logged into the system via IMAP, HTTP, POP, or some other mechanism.

IMAP、HTTP、POP、またはいくつかの他の機構を介してシステムにログインしたユーザをログイン。

The parameters include the domain name and port used to access the server and the user's authorization identity. Additional possible parameters include the client's IP address and port, the authentication identity (if different from the authorization identity), the service name, the authentication mechanism, information about any negotiated security layers, a timestamp, and other information.

パラメータは、サーバーとユーザーの許可IDをアクセスするために使用されるドメイン名とポートが含まれています。追加可能なパラメータは、クライアントのIPアドレスとポート、認証アイデンティティ(認可IDと異なる場合)、サービス名、認証機構、いかなる交渉したセキュリティレイヤについての情報、タイムスタンプ、およびその他の情報が含まれています。

Logout A user has logged out or otherwise been disconnected from the message store via IMAP, HTTP, POP, or some other mechanism.

ユーザがログアウトしたか、そうでなければ、IMAP、HTTP、POP、またはいくつかの他の機構を介してメッセージ・ストアから切断されてログアウト。

The parameters include the server domain name and the user's authorization identity. Additional parameters MAY include any of the information from the "Login" event as well as information about the type of disconnect (suggested values include graceful, abort, timeout, and security layer error), the duration of the connection or session, and other information.

パラメータは、サーバのドメイン名とユーザーの許可IDを含んでいます。追加のパラメータは、「ログイン」イベントからの情報だけでなく、切断のタイプ(推奨値は、中止、優雅なタイムアウト、およびセキュリティ層のエラーなどが)についての情報のいずれか、接続またはセッションの継続時間、およびその他の情報を含むことができます。

4.4. Mailbox Management
4.4. メールボックスの管理

This section lists events related to the management of mailboxes.

このセクションでは、メールボックスの管理に関連するイベントを示します。

MailboxCreate A mailbox has been created, or an access control changed on an existing mailbox so that it is now accessible by the user. If the mailbox creation caused the creation of new mailboxes earlier in the hierarchy, separate MailboxCreate events are not generated, as their creation is implied.

MailboxCreateメールボックスが作成された、またはそれが今、ユーザーがアクセスできるように、アクセス制御は、既存のメールボックスに変更されました。メールボックスの作成は、階層内の新しいメールボックスの作成は、以前発生した場合は、その作成を暗示されるように、別々のMailboxCreateイベントは、生成されません。

The parameters include the created mailbox identifier, its UIDVALIDITY for IMAP-accessible message stores, and MAY also indicate which access protocol triggered the event. Access and permissions information (such as Access Control List (ACL) [RFC4314] settings) require a standardized format to be included, and so are left for future extension.

パラメータは、作成されたメールボックス識別子、IMAPアクセス可能なメッセージストア用のUIDVALIDITY、および、イベントをトリガしたプロトコルにアクセスするかを示すかもしれないが含まれます。 (そのようなアクセス制御リスト(ACL)[RFC4314]の設定のような)アクセスおよび権限情報が含まれるための標準フォーマットを必要とし、したがって将来の拡張のために残されています。

MailboxDelete A mailbox has been deleted, or an access control changed on an existing mailbox so that it is no longer accessible by the user. Note that if the mailbox has child mailboxes, only the specified mailbox has been deleted, not the children. The mailbox becomes \NOSELECT, and the hierarchy remains unchanged, as per the description of the DELETE command in IMAP4rev1 [RFC3501].

MailboxDeleteメールボックスが削除されている、またはそれはもはや、ユーザがアクセスできるように、アクセス制御は、既存のメールボックスに変更されません。子供、メールボックスが子メールボックスを持っている場合は、必ず指定のメールボックスが削除されたことではないに注意してください。メールボックスは\ NOSELECTなり、階層はIMAP4rev1の[RFC3501]でDELETEコマンドの説明に従って、変更されません。

The parameters include the deleted mailbox identifier and MAY also indicate which access protocol triggered the event.

パラメータは、削除済みメールボックスの識別子を含めると、イベントをトリガしたプロトコルにアクセスするかを示すかもしれません。

MailboxRename A mailbox has been renamed. Note that, per the description of the RENAME command in IMAP4rev1 [RFC3501], special semantics regarding the mailbox hierarchy apply when INBOX is renamed (child mailboxes are usually included in the rename, but are excluded when INBOX is renamed). When a mailbox other than INBOX is renamed and its child mailboxes are also renamed as a result, separate MailboxRename events are not generated for the child mailboxes, as their renaming is implied. If the rename caused the creation of new mailboxes earlier in the hierarchy, separate MailboxCreate events are not generated for those, as their creation is implied. When INBOX is renamed, a new INBOX is created. A MailboxCreate event is not generated for the new INBOX, since it is implied.

MailboxRenameメールボックスの名前が変更されました。 IMAP4rev1の[RFC3501]でRENAMEコマンドの説明につき、INBOXの名前が変更されたときに、メールボックスの階層が適用に関する特別な意味は、(子メールボックスは通常、名前の変更に含まれていますが、INBOXの名前が変更されたときに除外されている)、それを注意してください。 INBOX以外のメールボックスの名前が変更され、その子のメールボックスも、結果として名前が変更された場合、その名前の変更が暗示されるように、別々のMailboxRenameイベントは、子メールボックスのために生成されていません。名前の変更は、階層内の新しいメールボックスの作成は、以前発生した場合は、その作成を暗示されるように、別々のMailboxCreateイベントは、それらのために生成されていません。 INBOXの名前が変更された場合、新しいINBOXが作成されます。それが暗示されているのでMailboxCreateイベントは、新しいINBOXのために生成されていません。

The parameters include the old mailbox identifier, the new mailbox identifier, and MAY also indicate which access protocol triggered the event.

パラメータは、古いメールボックス識別子、新しいメールボックス識別子、および、イベントをトリガしたプロトコルにアクセスするかを示すかもしれないが含まれます。

MailboxSubscribe A mailbox has been added to the server-stored subscription list, such as the one managed by the IMAP SUBSCRIBE and UNSUBSCRIBE commands.

MailboxSubscribeメールボックスは、このようなSUBSCRIBEとUNSUBSCRIBEコマンドIMAPによって管理される1つとして、サーバーに格納されたサブスクリプションリストに追加されました。

The parameters include the user whose subscription list has been affected, the mailbox identifier, and MAY also indicate which access protocol triggered the event.

パラメータは、そのサブスクリプションリスト影響を受けているユーザー、メールボックスの識別子を含む、また、アクセスプロトコルは、イベントをトリガしたかを示すかもしれません。

MailboxUnSubscribe A mailbox has been removed from the subscription list.

MailboxUnSubscribeメールボックスは、サブスクリプション・リストから削除されました。

The parameters include the user whose subscription list has been affected, the mailbox identifier, and MAY also indicate which access protocol triggered the event.

パラメータは、そのサブスクリプションリスト影響を受けているユーザー、メールボックスの識別子を含む、また、アクセスプロトコルは、イベントをトリガしたかを示すかもしれません。

5. Event Parameters
5.イベントのパラメータ

This section lists parameters included with these events.

このセクションでは、これらのイベントに含まれるパラメータを示しています。

admin Included with all events generated by message access protocols.

管理者は、メッセージアクセスプロトコルによって生成されたすべてのイベントに含まれています。

The authentication identity associated with this event, as distinct from the authorization identity (see "user"). This is not included when it is the same as the value of the user parameter.

認可IDとは異なり、このイベントに関連付けられた認証アイデンティティ、(「ユーザー」を参照)。それはユーザパラメータの値と同じであるとき、これは含まれていません。

bodyStructure May be included with MessageAppend and MessageNew.

BODYSTRUCTUREはMessageAppendとMessageNewに含まれていてもよいです。

The IMAP BODYSTRUCTURE of the message.

メッセージのIMAPのBODYSTRUCTURE。

clientIP Included with all events generated by message access protocols.

クライアントIPは、メッセージアクセスプロトコルによって生成されたすべてのイベントに含まれています。

The IPv4 or IPv6 address of the message store access client that performed the action that triggered the notification.

通知をトリガしたアクションを実行し、メッセージストアへのアクセスクライアントのIPv4またはIPv6アドレス。

clientPort Included with all events generated by message access protocols.

メッセージアクセスプロトコルによって生成されたすべてのイベントに付属CLIENTPORT。

The port number of the message store access client that performed an action that triggered the notification (the port from which the connection occurred).

通知(接続が発生したポート)をトリガーアクションを実行し、メッセージストア・アクセス・クライアントのポート番号。

diskQuota Included with QuotaExceed, QuotaWithin, and QuotaChange notifications relating to a user or mailbox disk quota. May be included with other notifications.

DISKQUOTAは、ユーザーまたはメールボックスディスククォータに関するQuotaExceed、QuotaWithin、およびQuotaChange通知に含まれています。他の通知に含まれていてもよいです。

Disk quota limit in kilobytes (1024 octets).

キロバイト単位でディスククォータの制限(1024オクテット)。

diskUsed Included with QuotaExceed and QuotaWithin notifications relating to a user or mailbox disk quota. May be included with other notifications.

diskUsedユーザーまたはメールボックスディスククォータに関するQuotaExceedとQuotaWithin通知に含まれています。他の通知に含まれていてもよいです。

Disk space used in kilobytes (1024 octets). Only disk space that counts against the quota is included.

キロバイト(1024オクテット)で使用されるディスク容量。クォータに対してカウントのみのディスクスペースが含まれています。

envelope May be included with the MessageNew notification.

エンベロープはMessageNew通知に含まれていてもよいです。

The message transfer envelope associated with final delivery of the message for the MessageNew notification. This includes the MAIL FROM and relevant RCPT TO line(s) used for final delivery with CRLF delimiters and any ESMTP parameters.

MessageNew通知のメッセージの最終的な配信に関連付けられたメッセージ転送エンベロープ。これは、CRLF区切り文字と任意ESMTPパラメータで最終的な送達のために使用されるライン(複数可)に、MAIL FROMと関連RCPTを含みます。

flagNames Included with FlagsSet and FlagsClear events. May be included with MessageAppend and MessageNew to indicate flags that were set initially by the APPEND command or delivery agent, respectively.

FlagsSetとFlagsClearイベントに含まflagNames。それぞれ、APPENDコマンドまたは配送エージェントによって最初に設定されたフラグを示すためにMessageAppendとMessageNewに含まれていてもよいです。

A list (likely to be space-separated) of IMAP flag or keyword names that were set or cleared. Flag names begin with a backslash while keyword names do not. The \Recent flag is explicitly not permitted in the list.

設定またはクリアされたIMAPフラグやキーワード名の(スペースで区切られた可能性が高い)のリスト。キーワード名がいない間、フラグ名は、バックスラッシュで始まります。 \ Recentフラグが明示的にリストで許可されていません。

mailboxID Included in events that affect mailboxes. A URI describing the mailbox. In the case of MailboxRename, this refers to the new name.

メイルボックスは、メールボックスに影響を与えるイベントに含まれています。 URIは、メールボックスを記述する。 MailboxRenameの場合、これは新しい名前を指します。

maxMessages Included with QuotaExceed and QuotaWithin notifications relating to a user or mailbox message count quota. May be included with other notifications.

ユーザーまたはメールボックスメッセージカウントクォータに関連QuotaExceedとQuotaWithin通知に含まmaxMessages。他の通知に含まれていてもよいです。

Quota limit on the number of messages in the mailbox, for events referring to a mailbox.

メールボックスを参照するイベントのためのメールボックス内のメッセージの数のクォータ制限、。

messageContent May be included with MessageAppend and MessageNew.

messageContentはMessageAppendとMessageNewに含まれていてもよいです。

The entire message itself. Size-based suppression of this SHOULD be available.

メッセージ全体そのもの。このサイズベースの抑制が利用可能であるべきです。

messageSize May be included with MessageAppend and MessageNew.

MESSAGESIZEはMessageAppendとMessageNewに含まれていてもよいです。

Size of the RFC 5322 message itself in octets. This value matches the length of the IMAP literal returned in response to an IMAP FETCH of BODY[] for the referenced message.

オクテットRFC 5322のメッセージ自体のサイズ。この値は、参照されるメッセージのBODY []のフェッチIMAPに応答して返されたリテラルIMAPの長さと一致します。

messages Included with QuotaExceed and QuotaWithin notifications relating to a user or mailbox message count quota. May be included with other notifications.

ユーザーまたはメールボックスメッセージカウントクォータに関連QuotaExceedとQuotaWithin通知に含まれたメッセージ。他の通知に含まれていてもよいです。

Number of messages in the mailbox. This is typically included with message addition and deletion events.

メールボックス内のメッセージの数。これは通常、メッセージの追加と削除イベントに含まれています。

modseq May be included with any notification referring to one message.

modseqは、一つのメッセージを参照するすべての通知に含まれていてもよいです。

This is the 64-bit integer MODSEQ as defined in [RFC4551]. No assumptions about MODSEQ can be made if this is omitted.

[RFC4551]で定義されるように、これは64ビット整数MODSEQあります。これが省略された場合MODSEQに関する仮定を行うことはできません。

oldMailboxID A URI describing the old name of a renamed or moved mailbox.

名前を変更または移動したメールボックスの古い名前を記述するURIをoldMailboxID。

pid May be included with any notification.

pidは任意の通知に含まれていてもよいです。

The process ID of the process that generated the notification.

通知を生成したプロセスのプロセスID。

process May be included with any notification.

プロセスは、任意の通知に含まれていてもよいです。

The name of the process that generated the notification.

通知を生成したプロセスの名前。

serverDomain Included in Login and optionally in Logout or other events. The domain name or IP address (v4 or v6) used to access the server or mailbox.

SERVERDOMAINログインに必要に応じてログアウトまたは他のイベントに含まれています。ドメイン名またはIPアドレス(V4またはV6)は、サーバーまたはメールボックスにアクセスするために使用されます。

serverPort Included in Login and optionally in Logout or other events. The port number used to access the server. This is often a well-known port.

するserverPortログインに必要に応じてログアウトまたは他のイベントに含まれています。サーバーへのアクセスに使用するポート番号。これは、多くの場合、よく知られたポートです。

serverFQDN May be included with any notification.

serverFQDNは、任意の通知に含まれていてもよいです。

The fully qualified domain name of the server that generated the event. Note that this may be different from the server name used to access the mailbox included in the mailbox identifier.

イベントを生成したサーバーの完全修飾ドメイン名。これは、メールボックスの識別子に含まれたメールボックスにアクセスするために使用されるサーバー名とは異なる場合がありますので注意してください。

service May be included with any notification.

サービスは、通知に含まれていてもよいです。

The name of the service that triggered the event. Suggested values include "imap", "pop", "http", and "admincli" (for an administrative client).

イベントをトリガしたサービスの名前。推奨値は、「IMAP」、「ポップ」、「HTTP」、および(管理クライアント用)「admincli」が挙げられます。

tags May be included with any notification.

タグは任意の通知に含まれていてもよいです。

A list of UTF-8 tags (likely to be comma-separated). One or more tags can be set at the time a notification criteria or notification subscription is created. Subscribers can use tags for additional client-side filtering or dispatch of events.

(カンマで区切られた可能性が高い)UTF-8タグのリスト。 1つまたは複数のタグは、通知基準や通知サブスクリプションの作成時に設定することができます。加入者は、追加のクライアント側のフィルタリングやイベントのディスパッチのためのタグを使用することができます。

timestamp May be included with any notification.

タイムスタンプは、任意の通知に含まれていてもよいです。

The time at which the event occurred that triggered the notification (the underlying protocol carrying the notification may contain a timestamp for when the notification was generated). This MAY be an approximate time.

イベント通知(通知が生成されたときのタイムスタンプを含むことができる通知を運ぶ基本的なプロトコル)をトリガし、その発生した時刻。これは、おおよその時間がかかるかもしれません。

Timestamps are expressed in local time and contain the offset from UTC (this information is used in several places in Internet mail) and are normally in [RFC3339] format.

タイムスタンプはローカルタイムで表されている(この情報は、インターネットメールに複数の場所で使用されている)UTCからのオフセットを含み、[RFC3339]の形式で通常です。

uidnext May be included with any notification referring to a mailbox.

UIDNEXTは、メールボックスを参照するすべての通知に含まれていてもよいです。

The UID that is projected to be assigned next in the mailbox. This is typically included with message addition and deletion events. This is equivalent to the UIDNEXT status item in the IMAP STATUS command.

投影されたUIDは、メールボックス内の次の割り当てられます。これは通常、メッセージの追加と削除イベントに含まれています。これは、IMAP STATUSコマンドでUIDNEXTステータス項目に相当します。

uidset Included with MessageExpires, MessageExpunges, MessageRead, MessageTrash, FlagsSet, and FlagsClear.

uidsetはMessageExpires、MessageExpunges、MessageRead、MessageTrash、FlagsSet、およびFlagsClearに含まれています。

This includes the set of IMAP UIDs referenced.

これは、参照のIMAPのUIDのセットが含まれています。

uri Included with all notifications. A reference to the IMAP server, a mailbox, or a message.

URIは、すべての通知に含まれています。 IMAPサーバ、メールボックス、またはメッセージを参照します。

Typically an IMAP URL. This can include the name of the server used to access the mailbox/message, the mailbox name, the UIDVALIDITY of the mailbox, and the UID of a specific message.

通常、IMAPのURL。これは、特定のメッセージのメールボックス/メッセージ、メールボックス名、メールボックスのUIDVALIDITY、およびUIDにアクセスするために使用されるサーバーの名前を含めることができます。

user Included with all events generated by message access protocols.

ユーザーは、メッセージアクセスプロトコルによって生成されたすべてのイベントに含まれています。

This is the authorization identifier used when the client connected to the access protocol that triggered the event. Some protocols (for example, many SASL mechanisms) distinguish between authorization and authentication identifiers. For events associated with a mailbox, this may be different from the owner of the mailbox specified in the IMAP URL.

これは、クライアントがイベントをトリガしたアクセスプロトコルに接続するときに使用する許可識別子です。 (例えば、多くのSASL機構)いくつかのプロトコルは、許可および認証の識別子を区別します。メールボックスに関連付けられたイベントの場合、これはIMAPのURLで指定したメールボックスの所有者と異なる場合があります。

6. IANA Considerations
6. IANAの考慮事項

The IANA has created a new registry for "Internet Message Store Events" that contains two sub-registries: event names and event parameters. For both event names and event parameters, entries that do not start with "vnd." are added by the IETF and are intended for interoperable use. Entries that start with "vnd." are intended for private use by one or more parties and are allocated to avoid collisions.

イベント名とイベントパラメータ:IANAは、2つのサブレジストリが含まれている「インターネットメッセージストアイベント」のための新しいレジストリを作成しました。イベント名とイベントパラメータの両方について、始まらないエントリ「VND。」 IETFによって追加され、相互運用可能な使用のために意図されています。始まるエントリ「VND。」一つ以上の当事者による私的使用のために意図されているとの衝突を避けるために割り当てられています。

The initial values are contained in this document.

初期値は、本文書に含まれています。

Using IANA Considerations [RFC5226] terminology, entries that do not start with "vnd." are allocated by IETF Consensus, while those starting with "vnd." are allocated First Come First Served.

IANAの考慮事項[RFC5226]の用語、始まらないエントリの使用「VNDを。」始まるものは、IETFコンセンサスによって割り当てられている「VND。」まず第一に役立っ来割り当てられています。

7. Security Considerations
7.セキュリティの考慮事項

Notifications can produce a large amount of traffic and expose sensitive information. When notification mechanisms are used to maintain state between different entities, the ability to corrupt or manipulate notification messages could enable an attacker to modulate the state of these entities. For example, if an attacker were able to modify notifications sent from a message store to an auditing server, he could modify the "user" and "messageContent" parameters in MessageNew notifications to create false audit log entries.

通知は大量のトラフィックを生成し、機密情報を公開することができます。通知メカニズムが異なるエンティティ間の状態を維持するために使用される場合、破損または通知メッセージを操作する能力は、これらのエンティティの状態を調節するために、攻撃者が可能性があります。攻撃者は、監査サーバーにメッセージストアから送信される通知を変更することができました場合たとえば、彼は偽の監査ログエントリを作成するには、「ユーザー」とMessageNew通知で「messageContent」パラメータを変更することができます。

A competent transfer protocol for notifications must consider authentication, authorization, privacy, and message integrity, as well as denial-of-service issues. While the IETF has adequate tools and experience to address these issues for mechanisms that involve only one TCP connection, notification or publish/subscribe protocols that are more sophisticated than a single end-to-end TCP connection will need to pay extra attention to these issues and carefully balance requirements to successfully deploy a system with security and privacy considerations.

通知のための有能な転送プロトコルは、認証、認可、プライバシー、およびメッセージの整合性だけでなく、サービス拒否の問題を考慮する必要があります。 IETFは、1つのTCP接続だけが関与するメカニズムのため、これらの問題に対処するための適切なツールと経験を有しているが、通知またはシングルエンド・ツー・エンドのTCP接続よりも洗練されているパブリッシュ/サブスクライブ・プロトコルは、これらの問題に特別な注意を払う必要があります。そして、慎重に成功し、セキュリティとプライバシーの考慮事項とシステムを配備するための要件のバランスをとります。

8. Acknowledgments
8.謝辞

Alexey Melnikov, Arnt Gulbrandsen, and Zoltan Ordogh have reviewed and offered improvements to this document. Richard Barnes did a nice review during Last Call.

アレクセイ・メルニコフ、ARNT Gulbrandsenの、とゾルタンOrdoghを見直し、このドキュメントの改善を提供してきました。リチャード・バーンズは、ラストコール中に素敵な見直しを行いました。

9. References
9.参考文献
9.1. Normative References
9.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月。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。

[RFC5092] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, November 2007.

[RFC5092]メルニコフ、A.とC.ニューマン、 "IMAP URLスキーム"、RFC 5092、2007年11月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。

9.2. Informative References
9.2. 参考文献

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[RFC1939]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。

[RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.

[RFC2177] Leiba、B.、 "IMAP4 IDLEコマンド"、RFC 2177、1997年6月。

[RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2447, November 1998.

[RFC2447]ドーソン、F.、マンスール、S.、およびS. Silverberg、 "のiCalendarメッセージベースの相互運用プロトコル(iMIPの)"、RFC 2447、1998年11月。

[RFC2616] 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.

[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。

[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.

[RFC3339] Klyne、G.、エド。そして、C.ニューマン、「インターネット上の日付と時刻:タイムスタンプ」、RFC 3339、2002年7月。

[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.

[RFC3458]バーガー、E.、Candell、E.、エリオット、C.、およびG. Klyne、 "インターネットメールのためのメッセージコンテキスト"、RFC 3458、2003年1月。

[RFC4146] Gellens, R., "Simple New Mail Notification", RFC 4146, August 2005.

[RFC4146] Gellens、R.、 "シンプル新着メールの通知"、RFC 4146、2005年8月。

[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.

[RFC4314]メルニコフ、A.、 "IMAP4アクセス制御リスト(ACL)拡張"、RFC 4314、2005年12月。

[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.

[RFC4422]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層(SASL)"、RFC 4422、2006年6月。

[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.

[RFC4467]のCrispin、M.、 "インターネットメッセージアクセスプロトコル(IMAP) - URLAUTH拡張"、RFC 4467、2006年5月。

[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.

[RFC4551]メルニコフ、A.とS.ホール、 "条件付きSTORE操作やクイックフラグの変更を再同期化のためのIMAP拡張"、RFC 4551、2006年6月。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。

Appendix A. Future Extensions

付録A.将来の拡張

This document specifies core functionality based on events that are believed to be well understood, have known use cases, and are implemented by at least one deployed real-world Internet message store. (A few events are exceptions to the last test only: FlagsSet, FlagsClear, MailboxCreate, MailboxDelete, MailboxRename, MailboxSubscribe, and MailboxUnSubscribe.)

この文書では、十分に理解されると考えられているイベント、ユースケースを知っていると、少なくとも1つの展開、実世界のインターネットメッセージストアによって実現されているに基づいてコア機能を指定します。 (いくつかのイベントが最後のテストのみの例外です:。FlagsSet、FlagsClear、MailboxCreate、MailboxDelete、MailboxRename、MailboxSubscribe、およびMailboxUnSubscribe)

Some events have been suggested but are postponed to future extensions because they do not meet this criteria. These events include messages that have been moved to archive storage and may require extra time to access, quota by message context, authentication failure, user mail account disabled, annotations, and mailbox ACL or metadata change. The descriptions of several events note additional parameters that are likely candidates for future inclusion. See Section 6 for how the list of events and parameters can be extended.

一部のイベントは、提案されているが、彼らは、この基準を満たしていないため、将来の拡張に延期されています。これらのイベントは、アーカイブストレージに移動されたとのアクセスに余分な時間を必要とするかもしれないメッセージ、メッセージコンテキストによってクォータ、認証失敗、ユーザーのメールアカウント無効、注釈、およびメールボックスのACLやメタデータの変更が含まれます。いくつかのイベントの記述は、将来のために含める可能性の高い候補である追加のパラメータに注意してください。イベントやパラメータのリストを拡張することができるかについては、セクション6を参照してください。

In order to narrow the scope of this document to something that can be completed, only events generated from the message store (by a message access module, administrative module, or message delivery agent) are considered. A complete mail system is normally linked with an identity system that would also publish events of interest to a message store event subscriber. Events of interest include account created/deleted/disabled and password changed/expired.

完了することができるものには、この文書の範囲を狭めるために、(メッセージ・アクセス・モジュール、管理モジュール、またはメッセージ配信エージェントによって)メッセージストアから生成されたイベントのみが考慮されます。完全なメールシステムは通常、メッセージストアイベント加入者に関心のあるイベントを公開しますアイデンティティシステムとリンクされています。興味のあるイベントは無効とパスワード/期限切れの変更/削除/作成したアカウントが含まれます。

Authors' Addresses

著者のアドレス

Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92651 USA

ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92651 USA

Phone: EMail: rg+ietf@qualcomm.com

電話番号:Eメール:rg+ietf@qualcomm.com

Chris Newman Sun Microsystems 800 Royal Oaks Monrovia, CA 91016-6347 USA

クリス・ニューマンSun Microsystemsの800ロイヤルオークスモンロビア、カリフォルニア州91016から6347 USA

Phone: EMail: chris.newman@sun.com

電話番号:Eメール:chris.newman@sun.com