RFC 5819 - IMAP4 Extension for Returning STATUS Information in Extended LIST 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5819
タイトル : RFC 5819 - 拡張リストでステータス情報を返すためのIMAP4拡張
翻訳編集 : 自動生成

[要約] RFC 5819は、IMAP4の拡張LISTでSTATUS情報を返すための拡張機能です。目的は、クライアントがメールボックスの状態を効率的に取得できるようにすることです。

Internet Engineering Task Force (IETF)                       A. Melnikov
Request for Comments: 5819                                 Isode Limited
Category: Standards Track                                    T. Sirainen
ISSN: 2070-1721                                             Unaffiliated
                                                              March 2010

IMAP4 Extension for Returning STATUS Information in Extended LIST

拡張リストでステータス情報を返すためのIMAP4拡張

Abstract

概要

Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command.

多くのIMAPクライアントは、IMAPメールボックスにメッセージの総数 /目に見えないメッセージの総数に関する情報を表示します。そのためには、リストまたはLSUBコマンドを発行し、利用可能なすべてのメールボックスをリストすることを余儀なくされ、見つかった各メールボックスのステータスコマンドが続きます。このドキュメントには、クライアントがメールボックスのステータス情報を要求できるようにする拡張機能コマンドを提供します。

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

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

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. STATUS Return Option to LIST Command ............................2
   3. Examples ........................................................3
   4. Formal Syntax ...................................................4
   5. Security Considerations .........................................4
   6. IANA Considerations .............................................4
   7. Acknowledgements ................................................5
   8. Normative References ............................................5

1. Introduction

1. はじめに

Many IMAP clients display information about the total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command.

多くのIMAPクライアントは、IMAPメールボックスのメッセージの総数 /目に見えないメッセージの総数に関する情報を表示します。そのためには、リストまたはLSUBコマンドを発行し、利用可能なすべてのメールボックスをリストすることを余儀なくされ、見つかった各メールボックスのステータスコマンドが続きます。このドキュメントには、クライアントがメールボックスのステータス情報を要求できるようにする拡張機能コマンドを提供します。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用されている規則

In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.

例では、「C：」は、サーバーに接続されているクライアントから送信された行を示します。「S：」は、サーバーからクライアントに送信された行を示します。

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

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [KWDS]に記載されているとおりに解釈されます。

2. STATUS Return Option to LIST Command

2. コマンドをリストするためのステータス戻りオプション

[RFC3501] explicitly disallows mailbox patterns in the STATUS command. The main reason was to discourage frequent use of the STATUS command by clients, as it might be quite expensive for an IMAP server to perform. However, this prohibition had resulted in an opposite effect: a new generation of IMAP clients appeared, that issues a STATUS command for each mailbox returned by the LIST command. This behavior is suboptimal to say at least. It wastes extra bandwidth and, in the case of a client that doesn't support IMAP pipelining, also degrades performance by using too many round trips. This document tries to remedy the situation by specifying a single command that can be used by the client to request all the necessary information. In order to achieve this goal, this document is extending the LIST command with a new return option, STATUS. This option takes STATUS data items as parameters. For each selectable mailbox matching the list pattern and selection options, the server MUST return an untagged LIST response followed by an untagged STATUS response containing the information requested in the STATUS return option.

[RFC3501]ステータスコマンドのメールボックスパターンを明示的に許可します。主な理由は、IMAPサーバーが実行するのに非常に高価かもしれないため、クライアントによるステータスコマンドの頻繁な使用を阻止することでした。ただし、この禁止は反対の効果をもたらしました。新しい世代のIMAPクライアントが表示され、リストコマンドによって返される各メールボックスのステータスコマンドを発行しました。この動作は、少なくとも言うのが最適です。それは余分な帯域幅を無駄にし、IMAPパイプラインをサポートしていないクライアントの場合、また多くの往復を使用することでパフォーマンスを低下させます。このドキュメントは、必要なすべての情報を要求するためにクライアントが使用できる単一のコマンドを指定することにより、状況を改善しようとします。この目標を達成するために、このドキュメントは、新しいリターンオプションであるステータスでリストコマンドを拡張しています。このオプションは、ステータスデータ項目をパラメーターとして使用します。リストのパターンと選択オプションに一致する選択可能なメールボックスごとに、サーバーは、ステータスリターンオプションで要求された情報を含む未積ばれたリスト応答と続いて、攻撃されていないリスト応答を返す必要があります。

If an attempted STATUS for a listed mailbox fails because the mailbox can't be selected (e.g., if the "l" ACL right [ACL] is granted to the mailbox and the "r" right is not granted, or due to a race condition between LIST and STATUS changing the mailbox to \NoSelect), the STATUS response MUST NOT be returned and the LIST response MUST include the \NoSelect attribute. This means the server may have to buffer the LIST reply until it has successfully looked up the necessary STATUS information.

メールボックスを選択できないためにリストされているメールボックスの試みのステータスが失敗した場合（たとえば、「l」ACL right [acl]がメールボックスに付与され、「r」権利が付与されない場合、またはレースのために「r」権利が付与されない場合リストとステータスの間の条件メールボックスを\ noselectに変更する）、ステータス応答を返す必要はなく、リスト応答に\ noselect属性を含める必要があります。これは、必要なステータス情報を正常に検索するまで、サーバーがリストの返信をバッファリングする必要がある場合があることを意味します。

If the server runs into unexpected problems while trying to look up the STATUS information, it MAY drop the corresponding STATUS reply. In such a situation, the LIST command would still return a tagged OK reply.

サーバーがステータス情報を検索しようとしているときに予期しない問題に実行された場合、対応するステータス応答がドロップされる場合があります。このような状況では、リストコマンドは引き続きタグ付きOK返信を返します。

3. Examples

3. 例

   C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
   S: * LIST () "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
   S: * LIST () "." "foo"
   S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
   S: * LIST (\NoSelect) "." "bar"
   S: A01 OK List completed.

The "bar" mailbox isn't selectable, so it has no STATUS reply.

「バー」メールボックスは選択できないため、ステータスの返信はありません。

   C: A02 LIST (SUBSCRIBED RECURSIVEMATCH)"" % RETURN (STATUS
      (MESSAGES))
   S: * LIST (\Subscribed) "."  "INBOX"
   S: * STATUS "INBOX" (MESSAGES 17)
   S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
   S: A02 OK List completed.

The LIST reply for "foo" is returned because it has matching children, but no STATUS reply is returned because "foo" itself doesn't match the selection criteria.

「foo」のリストの返信は、子供が一致するために返されますが、「foo」自体が選択基準と一致しないため、ステータスの返信は返されません。

4. Formal Syntax

4. 正式な構文

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [ABNF]. Terms not defined here are taken from [RFC3501] and [LISTEXT].

次の構文仕様では、[ABNF]で説明されているように、拡張されたバックナウル形式（BNF）を使用します。ここで定義されていない用語は、[rfc3501]および[listext]から取得されます。

return-option =/ status-option

status-option = "STATUS" SP "(" status-att *(SP status-att) ")" ;; This ABNF production complies with ;; <option-extension> syntax.

status-option = "status" sp "（" status-att *（sp status-att） "）" ;;このABNFの生産は、に準拠しています;;<Option-Extension>構文。

5. Security Considerations

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

This extension makes it a bit easier for clients to overload the server by requesting STATUS information for a large number of mailboxes. However, as already noted in the introduction, existing clients already try to do that by generating a large number of STATUS commands for each mailbox in which they are interested. While performing STATUS information retrieval for big lists of mailboxes, a server implementation needs to make sure that it can still serve other IMAP connections and yield execution to other connections, when necessary.

この拡張機能により、クライアントは多数のメールボックスのステータス情報を要求することで、クライアントがサーバーをオーバーロードしやすくなります。ただし、紹介ですでに述べたように、既存のクライアントは、興味のあるメールボックスごとに多数のステータスコマンドを生成することにより、すでにそれを実行しようとしています。メールボックスの大きなリストのステータス情報検索の実行中、サーバーの実装では、必要に応じて他のIMAP接続を提供し、他の接続に実行することができることを確認する必要があります。

6. IANA Considerations

6. IANAの考慮事項

IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The "IMAP 4 Capabilities" registry is available from the IANA webiste:

IMAP4機能は、標準トラックまたはIESGが承認した実験RFCを公開することにより登録されます。「IMAP 4機能」レジストリは、IANA Webisteから入手できます。

http://www.iana.org

This document defines the LIST-STATUS IMAP capability. IANA has added it to the registry.

このドキュメントでは、リストステータスIMAP機能を定義します。IANAはそれをレジストリに追加しました。

IANA has also added the following new LIST-EXTENDED option to the IANA registry established by [LISTEXT]:

IANAは、[ListExt]によって確立されたIANAレジストリに次の新しいリスト拡張オプションを追加しました。

To: iana@iana.org Subject: Registration of LIST-EXTENDED option STATUS

宛先：iana@iana.org件名：リスト拡張オプションステータスの登録

LIST-EXTENDED option name: STATUS

リスト拡張オプション名：ステータス

LIST-EXTENDED option type: RETURN

リスト拡張オプションタイプ：返品

LIST-EXTENDED option description: Causes the LIST command to return STATUS responses in addition to LIST responses.

リスト拡張オプション説明：リストコマンドがリスト応答に加えてステータス応答を返します。

Published specification: RFC 5819

公開された仕様：RFC 5819

Security considerations: RFC 5819

セキュリティ上の考慮事項：RFC 5819

Intended usage: COMMON

意図された使用法：共通

   Person and email address to contact for further information:
   Alexey Melnikov <Alexey.Melnikov@isode.com>

Owner/Change controller: iesg@ietf.org

所有者/変更コントローラー：iesg@ietf.org

7. Acknowledgements

7. 謝辞

Thanks to Philip Van Hoof who pointed out that STATUS and LIST commands should be combined in order to optimize traffic and number of round trips.

トラフィックと往復数を最適化するために、ステータスとリストコマンドを組み合わせる必要があることを指摘したフィリップヴァンホーフに感謝します。

8. Normative References

8. 引用文献

[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[ABNF] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。

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

[ACL] Melnikov、A。、「IMAP4アクセス制御リスト（ACL）拡張機能」、RFC 4314、2005年12月。

[Kwds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[KWDS] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[LISTEXT] Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, June 2008.

[Listext] Leiba、B。およびA. Melnikov、「インターネットメッセージアクセスプロトコルバージョン4-リストコマンド拡張機能」、RFC 5258、2008年6月。

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

[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。

Authors' Addresses

著者のアドレス

Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK

Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK

   EMail: Alexey.Melnikov@isode.com
   URI:   http://www.melnikov.ca/

Timo Sirainen

ティモ・シランエン

   EMail: tss@iki.fi