[要約] RFC 8970は、IMAP4プロトコルにメッセージプレビュー生成の拡張機能を追加するものです。この拡張機能の目的は、ユーザーがメール本文を開かずに内容の概要を確認できるようにすることです。主にメールクライアントがメールの概要を表示する際や、大量のメールを効率的に処理する場面で利用されます。
Internet Engineering Task Force (IETF) M. Slusarz
Request for Comments: 8970 Open-Xchange Inc.
Category: Standards Track December 2020
ISSN: 2070-1721
IMAP4 Extension: Message Preview Generation
IMAP4拡張：メッセージプレビュー生成
Abstract
概要
This document specifies an Internet Message Access Protocol (IMAP) protocol extension that allows a client to request a server-generated abbreviated text representation of message data that is useful as a contextual preview of the entire message.
このドキュメントは、メッセージ全体のコンテキストプレビューとして有用なメッセージデータのサーバーで生成されたテキスト表現をクライアントに要求できるようにするインターネットメッセージアクセスプロトコル（IMAP）プロトコル拡張を指定します。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8970.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8970で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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ドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. FETCH Data Item
3.1. Command
3.2. Response
3.3. Preview Text Format
4. LAZY Priority Modifier
4.1. LAZY
4.2. Client Implementation Advice
5. Examples
6. Formal Syntax
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Author's Address
Many modern mail clients display small extracts of the body text as an aid to allow a user to quickly decide whether they are interested in viewing the full message contents. Mail clients implementing the Internet Message Access Protocol [RFC3501] would benefit from a standardized, consistent way to generate these brief textual previews of messages.
多くの最新のメールクライアントは、ユーザーが完全なメッセージの内容を見ることに興味があるかどうかをユーザーがすばやく決定できるようにするための補助テキストの小さな抽出物を表示します。インターネットメッセージアクセスプロトコルを実装するメールクライアント[RFC3501]は、これらの簡単なテキストプレビューを生成するための標準化された一貫した方法から利益を得るでしょう。
Generation of a preview on the server has several benefits. First, it allows consistent representation of previews across all clients. While different clients might generate quite different preview text, having common preview text generated by the server can give a more consistent user experience to those who use multiple clients.
サーバー上のプレビューの生成にはいくつかの利点があります。まず、すべてのクライアントにわたるプレビューの一貫した表現を可能にします。さまざまなクライアントが非常に異なるプレビューテキストを生成する可能性がありますが、サーバーによって生成された一般的なプレビューテキストを持つことは、複数のクライアントを使用するユーザーに対してより一貫したユーザーエクスペリエンスを与えることができます。
Second, server-side preview generation is more efficient. A client-based algorithm needs to issue, at a minimum, a FETCH BODYSTRUCTURE command in order to determine which MIME [RFC2045] body part(s) should be represented in the preview. Subsequently, at least one FETCH BODY command may be needed to retrieve body data used in preview generation. These FETCH commands cannot be pipelined since the BODYSTRUCTURE query must be parsed on the client before the list of parts to be retrieved via the BODY command(s) can be determined.
第二に、サーバ側のプレビュー生成はより効率的である。クライアントベースのアルゴリズムは、どのMIME [RFC2045]本体部分をプレビューで表す必要があるかを決定するために、最低限のフェッチ本体構造コマンドを発行する必要がある。続いて、プレビュー生成で使用されるボディデータを検索するために、少なくとも1つのフェッチ本体コマンドが必要とされ得る。ボディコマンドを介して取得する部分のリストを決定することができる前に、BodyStructureクエリをクライアントに解析する必要があるため、これらのFETCHコマンドをパイプライン化できません。
Additionally, it may be difficult to predict the amount of body data that must be retrieved to adequately represent the part via a preview, therefore requiring inefficient fetching of excessive data in order to account for this uncertainty. For example, a preview algorithm to display data contained in a text/html [RFC2854] part will likely strip the markup tags to obtain textual content. However, without fetching the entire content of the part, there is no way to guarantee that sufficient non-tag content will exist unless either 1) the entire part is retrieved or 2) an additional partial FETCH is executed when the client determines that it does not possess sufficient data from a previous partial FETCH to display an adequate representation of the preview.
さらに、プレビューを介して部品を適切に表現するために検索されなければならないボディデータの量を予測することは困難であり得、したがって、この不確実性を説明するために過度のデータを非効率的にフェッチすることを必要とする。例えば、Text / HTML [RFC2854]部分に含まれるデータを表示するためのプレビューアルゴリズムは、マークアップタグを削除してテキスト内容を取得する可能性があります。ただし、パートの内容全体を取得することなく、1）部分全体が取得されていない場合は十分な非タグコンテンツが存在することが保証されていないか、または2）追加の部分フェッチが実行されたときに実行されます。前の部分フェッチから十分なデータを持っていないため、プレビューの適切な表現を表示します。
Finally, server generation allows caching in a centralized location. Using server-generated previews allows global generation once per message, and that preview can be cached for the retention period of the source message. Retrieval of message data may be expensive within a server, for example, so a server can be configured to reduce its storage retrieval load by pre-generating preview data.
最後に、サーバー生成により、キャッシュが集中位置にあることができます。サーバーで生成されたプレビューを使用すると、メッセージごとに1回のグローバル生成を許可し、そのプレビューをソースメッセージの保存期間にキャッシュできます。メッセージデータの検索は、例えば、サーバ内の高価であり得るので、サーバは、プレビューデータを事前生成することによってその記憶検索負荷を減少させるように構成することができる。
A server indicates support for this extension via the "PREVIEW" capability name.
サーバーは、「プレビュー」機能名を介してこの拡張のサポートを示します。
The 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
"User" is used to refer to a human user, whereas "client" refers to the software being run by the user.
"user"は人間のユーザーを指すために使用されますが、 "クライアント"はユーザーが実行中のソフトウェアを指します。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
例では、 "c："と "s："それぞれクライアントとサーバーによって送信された行を示します。単一の "C："または "S："ラベルが複数の行に適用される場合、それらの行の間のラインが復行することは編集的な明確さのためだけであり、実際のプロトコル交換の一部ではありません。
As with all IMAP extension documents, the case used in writing IMAP protocol elements herein is chosen for editorial clarity, and implementations must pay attention to the numbered rules at the beginning of Section 9 of [RFC3501].
すべてのIMAP拡張文書と同様に、ここでのIMAPプロトコル要素の書き込みに使用される場合は、編集的な明確さのために選択され、実装は[RFC3501]のセクション9の冒頭で番号付きの規則に注意を払わなければなりません。
To retrieve a preview for a message, the PREVIEW FETCH attribute is used when issuing a FETCH command.
メッセージのプレビューを取得するには、fetchコマンドを発行するときにプレビューフェッチ属性が使用されます。
The server returns a variable-length string that is the generated preview for that message. This string is intended to be viewed by the user as a contextual preview of the entire message and is not intended to be interpreted in any way by the client software.
サーバーは、そのメッセージの生成されたプレビューである可変長文字列を返します。この文字列は、メッセージ全体のコンテキストプレビューとしてユーザーによって表示されることを意図しており、クライアントソフトウェアによって決して解釈されることを意図していません。
Example: Retrieving preview information in a SELECTed mailbox.
例：選択したメールボックス内のプレビュー情報を取得します。
C: A1 FETCH 1 (PREVIEW)
S: * 1 FETCH (PREVIEW "Preview text!")
S: A1 OK FETCH complete.
A server SHOULD strive to generate the same string for a given message for each request. However, since previews are understood to be an approximation of the message data and not a canonical view of its contents, a client MUST NOT assume that a message preview is immutable for a given message. This relaxed requirement permits a server to offer previews as an option without requiring potentially burdensome storage and/or processing requirements to guarantee immutability for a use case that does not require this strictness. For example, the underlying IMAP server may change due to a system software upgrade; an account's state information may be retained in the migration, but the new server may generate different preview text than the old server.
サーバーは、各要求に対して特定のメッセージに対して同じ文字列を生成するように努力してください。しかしながら、プレビューはその内容の正規ビューではなくメッセージデータの近似であると理解されるので、クライアントはメッセージプレビューが所与のメッセージに対して不変であると仮定してはならない。このリラックスした要件は、この厳密性を必要としないユースケースの不変性を保証するために、潜在的に煩わしい保存および/または処理要件を必要とせずに、サーバーがプレビューをオプションとして提供することを可能にします。たとえば、基本的なIMAPサーバーはシステムソフトウェアのアップグレードにより変更されることがあります。アカウントの状態情報は移行に保持される可能性がありますが、新しいサーバーは古いサーバーとは異なるプレビューテキストを生成することがあります。
It is possible that the server has determined that no meaningful preview text can be generated for a particular message. Examples of this involve encrypted messages, content types the server does not support previews of, and other situations where the server is not able to extract information for a preview. In such cases, the server MUST return a zero-length string. Clients SHOULD NOT send another FETCH for a preview for such messages. (As discussed previously, preview data is not immutable, so there is chance that at some point in the future the server would be able to generate meaningful text. However, this scenario is expected to be rare, so a client should not continually send out requests to try to detect this infrequent occurrence.)
特定のメッセージに対して意味のあるプレビューテキストが生成されないとサーバーが決定された可能性があります。これの例には、暗号化されたメッセージ、サーバーがプレビューをサポートしていないコンテンツタイプ、およびサーバーがプレビューの情報を抽出できない他の状況をサポートしていません。そのような場合、サーバーは長さゼロの文字列を返す必要があります。クライアントは、そのようなメッセージのプレビューに別のフェッチを送信しないでください。（前述したように、プレビューデータは不変ではありませんので、将来的にはサーバーが意味のあるテキストを生成できるようになる可能性があります。ただし、このシナリオはまれになると予想されるので、クライアントは絶えず送信してはいけません。このまれな発生を検出しようとする要求。）
If the LAZY modifier (Section 4.1) is used, the server MAY return NIL for the preview response, indicating that preview generation could not be completed without causing undue delay. A server MUST NOT return NIL to a FETCH PREVIEW request made without the LAZY modifier.
遅延修飾子（セクション4.1）が使用されている場合、サーバーはプレビュー応答に対してNILを返すことができ、過度の遅延を引き起こさずにプレビュー生成を完了できなかったことを示します。サーバーは、遅延修飾子なしで作成されたフェッチプレビュー要求にNILを返してはいけません。
The generated preview text MUST be treated as text/plain [RFC2046] media type data by the client.
生成されたプレビューテキストは、クライアントによってテキスト/平文[RFC2046]メディアタイプデータとして扱われなければなりません。
The generated string MUST NOT be content transfer encoded and MUST be encoded in UTF-8 [RFC3629]. The server SHOULD remove any formatting markup and do whatever processing might be useful in rendering the preview as plain text.
生成された文字列はコンテンツ転送エンコードではなく、UTF-8 [RFC3629]でエンコードする必要があります。サーバーはフォーマットマークアップを削除する必要があります。プレビューをプレーンテキストとしてレンダリングするのに役立つ場合は、何でも役に立ちます。
For purposes of this section, a "preview character" is defined as a single Universal Character Set (UCS) character encoded in UTF-8. Note: a single preview character may comprise multiple octets, so any buffers implemented to conform to the string limitations identified in this document should be sized to prevent possible overflow errors.
このセクションの目的のために、「プレビュー文字」は、UTF-8でエンコードされた単一のユニバーサル文字セット（UCS）文字として定義されています。注：単一のプレビューキャラクタは複数のオクテットを含み得るので、この文書で識別されている文字列制限に準拠するように実装されているバッファは、オーバーフローエラーを防ぐために大きくする必要があります。
The server SHOULD limit the length of the preview text to 200 preview characters. This length should provide sufficient data to generally support both various languages (and their different average word lengths) and diverse client display size requirements.
サーバーはプレビューテキストの長さを200のプレビュー文字に制限する必要があります。この長さは、一般的にさまざまな言語（およびそれらの異なる平均単語長）および多様なクライアント表示サイズ要件を一般的にサポートするのに十分なデータを提供する必要があります。
The server MUST NOT output preview text longer than 256 preview characters.
サーバーは、プレビューテキストを256文字を超えるプレビュー文字を出力してはいけません。
If the preview is not generated based on the body content of the message, and the LANGUAGE extension [RFC5255] is supported by the server, the preview text SHOULD be generated according to the language rules that apply to human-readable text. For example, a message that consists of a single image MIME part has no human-readable text from which to generate preview information. Instead, the server may wish to output a description that the message contains an image and describe some attributes of the image, such as image format, size, and filename. This descriptive text is not a product of the message body itself but is rather auto-generated data by the server; it should thus use the rules defined for human-readable text described in the LANGUAGE extension (if supported on the server).
メッセージのボディコンテンツに基づいてプレビューが生成されず、Language Extension [RFC5255]がサーバーでサポートされている場合、プレビューテキストは、人間が読めるテキストに適用される言語規則に従って生成されます。例えば、単一の画像MIME部分からなるメッセージは、プレビュー情報を生成する人間が読めるテキストを有していない。代わりに、サーバはメッセージが画像を含む記述を出力し、画像フォーマット、サイズ、およびファイル名などの画像の属性をいくつか記述したいと思うかもしれない。この記述的なテキストは、メッセージ本体自体の製品ではなく、サーバーによる自動生成データでもあります。したがって、言語拡張機能（サーバ上でサポートされている場合）に記載されている人間が読めるテキストに定義されている規則を使用する必要があります。
The LAZY modifier directs the server to return the preview representation only if that data can be returned without undue delay to the client.
遅延修飾子は、クライアントに過度の遅延なしでデータを返すことができる場合にのみ、サーバーにプレビュー表現を返すように指示します。
If this modifier is used, and the server is unable to return preview data without undue delay, the server MUST return NIL as the preview response.
この修飾子が使用され、サーバーが過度の遅延なしでプレビューデータを返すことができない場合、サーバーはプレビュー応答としてNILを返す必要があります。
The LAZY modifier MUST be implemented by any server that supports the PREVIEW extension.
遅延修飾子は、プレビュー拡張機能をサポートする任意のサーバーによって実装する必要があります。
Upon opening a mailbox, a client generally performs a FETCH of message details in order to create a listing to present to the user (e.g., ENVELOPE data). Using this extension, a client may want to additionally display preview information as part of this listing. Quickly providing the base mailbox listing with basic message details is the primary goal of this command as this is required to allow the user to begin interacting with the mailbox. Preview data is likely to be of secondary importance; it provides useful context, but it is not necessary to perform message actions. A client can load unavailable previews in the background and display them asynchronously to the user as the preview data is provided by the server.
メールボックスを開くと、クライアントは一般に、ユーザに存在するリストを作成するためにメッセージの詳細のフェッチを実行する（例えば、エンベロープデータ）。この拡張機能を使用すると、クライアントはこのリストの一部としてプレビュー情報を追加的に表示することをお勧めします。基本的なメッセージの詳細を付けて基本メールボックスのリストをすばやく提供するユーザーがメールボックスとの対話を開始することを許可するために必要なので、このコマンドの主な目標です。プレビューデータは二次的な重要性がある可能性があります。それは便利なコンテキストを提供しますが、メッセージアクションを実行する必要はありません。クライアントは、バックグラウンドで使用不可のプレビューをロードし、プレビューデータがサーバーによって提供されるため、ユーザーに非同期的に表示できます。
In this scenario, the client would add the PREVIEW data item, with the LAZY modifier, to the list of FETCH items needed to generate the mailbox listing. This allows the server to advantageously return preview data without blocking the primary goal of quickly returning the basic message details used to generate the mailbox listing.
このシナリオでは、クライアントは、メールボックスのリストを生成するために必要なフェッチ項目のリストに、クライアントはプレビューデータ項目をFETCHアイテムのリストに追加します。これにより、メールボックスリストの生成に使用された基本的なメッセージの詳細を迅速に返すという主な目標を遮断することなく、サーバーはプレビューデータを返すことができます。
Once this initial FETCH is complete, the client can then issue FETCH requests, without the LAZY modifier, to load the PREVIEW data item for the messages in which preview data was not returned. It is RECOMMENDED that these FETCH requests be issued in small batches, e.g., 50 messages per FETCH command, since preview generation may be expensive and a single large request may exceed server resource limits.
この初期フェッチが完了すると、クライアントは遅延修飾子なしでフェッチ要求を発行し、プレビューデータが返されなかったメッセージのプレビューデータ項目をロードできます。プレビュー生成は高価であり、単一の大きな要求がサーバリソースの制限を超える可能性があるため、これらのフェッチ要求は小さなバッチ、例えばFETCHコマンドごとのメッセージで発行されることをお勧めします。
See Example 2 in Section 5 for an implementation of this strategy.
この戦略の実装については、セクション5の実施例2を参照してください。
A client SHOULD NOT continually issue FETCH PREVIEW requests with the LAZY modifier in a selected mailbox as the server is under no requirement to return preview information for this command, which could lead to an unnecessary waste of system and network resources.
このコマンドのプレビュー情報を返す必要がなく、システムとネットワークリソースの不要な無駄になる可能性があるため、クライアントは選択したメールボックス内の遅延調整依頼を使用してフェッチプレビューリクエストを継続的に発行してはいけません。
Example 1: Requesting preview without LAZY modifier.
例1：遅延修飾子なしでプレビューを要求します。
C: A1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW
S: A1 OK Capability command completed.
[...a mailbox is SELECTed...]
C: A2 FETCH 1 (RFC822.SIZE PREVIEW)
S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW {200}
S: Lorem ipsum dolor sit amet, consectetur adipiscing elit.
S: Curabitur aliquam turpis et ante dictum, et pulvinar dui congue.
S: Maecenas hendrerit, lorem non imperdiet pellentesque, nulla
S: ligula nullam
S: )
S: A2 OK FETCH complete.
Example 2: Requesting preview with LAZY modifier, to obtain previews during initial mailbox listing if readily available; otherwise, load previews in background.
例2：遅延修飾子を使ってプレビューを要求し、すみまして入手可能な場合は初期メールボックスリスト中にプレビューを取得します。それ以外の場合は、バックグラウンドでプレビューをロードします。
C: B1 FETCH 1:4 (ENVELOPE PREVIEW (LAZY))
S: * 1 FETCH (ENVELOPE ("Wed, 23 Sep 2020 15:03:11 +0000" [...])
PREVIEW "Preview text for message 1.")
S: * 2 FETCH (PREVIEW "" ENVELOPE
("Thu, 24 Sep 2020 12:17:23 +0000" [...]))
S: * 3 FETCH (ENVELOPE ("Fri, 25 Sep 2020 09:13:45 +0000" [...])
PREVIEW NIL)
S: * 4 FETCH (ENVELOPE ("Sat, 26 Sep 2020 07:11:18 +0000" [...])
PREVIEW NIL)
S: B1 OK FETCH completed.
[...Client has preview for message 1 and knows that message 2 has
a preview that is empty; only need to request preview of
messages 3 & 4 (e.g., in background)...]
C: B2 FETCH 3:4 (PREVIEW)
S: * 3 FETCH (PREVIEW {30}
S: Message data from message 3.
S: )
S: * 4 FETCH (PREVIEW "Message 4 preview")
S: B2 OK Fetch completed.
Example 3: Requesting preview for search results within a single mailbox. Use the SEARCHRES extension [RFC5182] to save a round-trip.
例3：単一のメールボックス内の検索結果のプレビューを要求します。往復を保存するには、SearchRes拡張[RFC5182]を使用してください。
C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES
S: C1 OK Capability command completed.
[...a mailbox is SELECTed...]
C: C2 SEARCH RETURN (SAVE) FROM "FOO"
C: C3 FETCH $ (UID PREVIEW (LAZY))
S: C2 OK SEARCH completed.
S: * 5 FETCH (UID 13 PREVIEW "Preview!")
S: * 9 FETCH (UID 23 PREVIEW NIL)
S: C3 OK FETCH completed.
[...Retrieve message 9 preview in background...]
C: C4 UID FETCH 23 (PREVIEW)
S: * 9 FETCH (UID 23 PREVIEW "Another preview!")
S: C4 OK FETCH completed.
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. It includes definitions from IMAP [RFC3501].
次の構文仕様は、[RFC5234]に記載されているように拡張された背景 - Naur形式（ABNF）を使用します。IMAP [RFC3501]からの定義が含まれています。
capability =/ "PREVIEW"
機能= /「プレビュー」
fetch-att =/ "PREVIEW" [SP "(" preview-mod *(SP
preview-mod) ")"]
msg-att-dynamic =/ "PREVIEW" SP nstring
MSG-ATT-DYNAMIC = /「プレビュー」SP NSTRING
preview-mod = "LAZY"
IMAP [RFC3501] capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC in the "IMAP Capabilities" registry located at <http://www.iana.org/assignments/imap-capabilities>.
IMAP [RFC3501]機能は、<http：//www.iana.org/assignments/imap-capabilities>にある「IMAP機能」レジストリに標準トラックまたはIESG承認の実験的RFCを発行することによって登録されています。
IANA has added the "PREVIEW" capability to this registry.
IANAはこのレジストリに「プレビュー」機能を追加しました。
Implementation of this extension might enable denial-of-service attacks against server resources, due to excessive memory or CPU usage during preview generation or increased storage usage if preview results are stored on the server after generation. In order to mitigate such attacks, servers SHOULD log the client authentication identity on FETCH PREVIEW operations in order to facilitate tracking of abusive clients.
この拡張機能の実装は、プレビュー生成中のメモリまたはCPU使用率のため、サーバーリソースや、プレビューの結果が生成後にサーバーに保存されている場合に、サーバーリソースに対するサービス拒否攻撃を可能にします。そのような攻撃を軽減するために、サーバーは、虐待的なクライアントの追跡を容易にするために、プレビュー操作をフェッチするためにクライアント認証IDを記録する必要があります。
Servers MAY limit the resources that preview generation uses. Such resource limitations might, in an extreme example, cause a server to return a preview that is the empty string for a message that otherwise would have had a non-empty preview. However, it is recommended that at least some preview text be provided in this situation, even if the quality of the preview is degraded.
サーバーは、プレビュー生成が使用するリソースを制限する可能性があります。そのようなリソースの制限は、extremeの例では、そうでなければ空でないプレビューを持っていたメッセージの空の文字列であるプレビューをサーバーに返します。ただし、プレビューの品質が低下しても、この状況で少なくとも一部のプレビューテキストを提供することをお勧めします。
Just as the messages they summarize, preview data may contain sensitive information. If generated preview data is stored on the server, e.g., for caching purposes, these previews MUST be protected with equivalent authorization and confidentiality controls as the source message.
それらが要約するメッセージとして、プレビューデータに機密情報が含まれている可能性があります。生成されたプレビューデータはサーバに保存されている場合、例えばキャッシング目的で、これらのプレビューは、ソースメッセージとして同等の許可および機密性制御で保護する必要があります。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N.およびN.Borenstein、「MultiPurpose Internet Mail Extensions（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<https：//www.rfc-editor.org/ info / rfc2046>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3501]クリスピン、M.、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<https：//www.rfc-editor.org/info/rfc3501>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/RFC3629>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, DOI 10.17487/RFC5255, June 2008, <https://www.rfc-editor.org/info/rfc5255>.
[RFC5255] Newman、C、Gulbrandsen、A.、A.Melnikov、「インターネットメッセージアクセスプロトコル国際化」、RFC 5255、DOI 10.17487 / RFC5255、2008年6月、<https：//www.rfc-editor.org/Info / RFC5255>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N.およびN.Borenstein、「マルチポーズインターネットメール拡張（MIME）パート1：インターネットメッセージボディのフォーマット」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<https：///www.rfc-editor.org/info/rfc2045>。
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, DOI 10.17487/RFC2854, June 2000, <https://www.rfc-editor.org/info/rfc2854>.
[RFC2854] Connolly、D.およびL.Masinter、 "The Text / HTML 'メディアタイプ"、RFC 2854、DOI 10.17487 / RFC2854、2000年6月、<https：//www.rfc-editor.org/info/rfc2854>。
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March 2008, <https://www.rfc-editor.org/info/rfc5182>.
[RFC5182]メルニコフ、A。、「最後の検索結果を参照するためのIMAP拡張」、RFC 5182、DOI 10.17487 / RFC5182、2008年3月、<https：//www.rfc-editor.org/info/rfc5182>。
Acknowledgments
謝辞
The author would like to thank the following people for their comments and contributions to this document: Stephan Bosch, Bron Gondwana, Teemu Huovila, Neil Jenkins, Steffen Lehmann, Barry Leiba, Alexey Melnikov, Chris Newman, Pete Resnick, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi.
著者は、この文書へのコメントや貢献のために次の人々に感謝したいです.Stephan Bosch、Bron Gondwana、Teemu Huovila、Neil Jenkins、Steffen Lehmann、Barry Leiba、Alexey Melnikov、Chris Newman、Pete Resnick、Jeff Sipek、Timo Sirainen、Steffen Templin、Aki Tuomi。
Author's Address
著者の住所
Michael M. Slusarz Open-Xchange Inc. 530 Lytton Avenue Palo Alto, California 94301 United States of America
Michael M. Slusarz Open-Xchange Inc. 530 Lytton Avenue Palo Alto、カリフォルニア94301アメリカ合衆国
Email: michael.slusarz@open-xchange.com