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

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

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メールボックス内の見えないメッセージの総数に関する情報を表示します。そのために、彼らは、LISTまたはLSUBコマンドを発行し、見つかった各メールボックスのSTATUSコマンドに続いて、利用可能なすべてのメールボックスを一覧表示することを余儀なくされています。この文書では、クライアントは通常、LISTコマンドによって返された他の情報と一緒に、メールボックスのステータス情報を要求することを可能にするLISTコマンドへの拡張を提供します。

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.

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

著作権表示

著作権（C）2010 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. 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メールボックス内の見えないメッセージの合計数の合計数に関する情報を表示します。そのために、彼らは、LISTまたはLSUBコマンドを発行し、見つかった各メールボックスのSTATUSコマンドに続いて、利用可能なすべてのメールボックスを一覧表示することを余儀なくされています。この文書では、クライアントは通常、LISTコマンドによって返された他の情報と一緒に、メールボックスのステータス情報を要求することを可能にするLISTコマンドへの拡張を提供します。

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

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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]は明示的にSTATUSコマンドでメールボックスのパターンを禁止します。主な理由は、IMAPサーバーで実行するのは非常に高価であるかもしれないとして、クライアントによってSTATUSコマンドを頻繁に使用を阻止することでした。しかし、この禁止は逆効果が生じていた：IMAPクライアントの新世代は、LISTコマンドによって返された各メールボックスのSTATUSコマンドを発行している、登場しました。この動作は、少なくとも言って、準最適です。これは、余分な帯域幅を浪費して、IMAPのパイプライン化をサポートしていないクライアントの場合には、あまりにも多くのラウンドトリップを使用してパフォーマンスが低下します。この文書では、すべての必要な情報を要求するために、クライアントによって使用できる単一のコマンドを指定することで、状況を改善しようとします。この目標を達成するために、この文書は、新しいリターン・オプション、STATUSでLISTコマンドを拡張しています。このオプションは、パラメータとしてSTATUSデータ項目をとります。リストパターンと選択オプションに一致する各選択メールボックスに対して、サーバは、ステータス返信オプションで要求された情報を含むタグなしのステータス応答に続くタグ無しLIST応答を返さなければなりません。

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右[ACL]をメールボックスと「R」に付与されている場合例えば、右の付与された、または起因するレースにされていません（選択することはできませんので、記載されたメールボックスの未遂STATUSが失敗した場合LISTおよびSTATUS \ NOSELECTにメールボックスを変更する）の間の条件は、STATUS応答が返されてはならないとLIST応答が\ NOSELECT属性を含まなければなりません。これは、サーバが、それが必要なステータス情報を成功裏に見上げたまでLIST応答をバッファリングする必要がありますを意味します。

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.

STATUS情報を検索しようとしているときに、サーバーが予期しない問題に遭遇した場合は、対応するステータス応答を低下することがあります。このような状況では、LISTコマンドがまだタグ付けされた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.

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） "バー" S：A01 OK一覧が完了しました。

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

「バー」のメールボックスを選択することはできませんので、それは何のSTATUS応答がありません。

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.

C：A02 LIST（加入RECURSIVEMATCH） "" ％のRETURN（STATUS（メッセージ））S：* LIST（\購読） "" "INBOX" S：* STATUS "INBOX"（MESSAGES 17）S： "" * LIST（） "foo" という（CHILDINFO（ "加入"））S：A02 OK一覧が完了しました。

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」というためのLIST応答が返されますが、「foo」という自身が選択基準と一致していないので、何のSTATUS応答が返されません。

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" SP "（" ステータスのatt *（SPステータス-ATT） "）" ;;このABNF生産はに準拠しています;; <オプションの拡張>構文。

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.

この拡張は、それが少し簡単にクライアントが多数のメールボックスのステータス情報を要求することにより、サーバが過負荷にすることを可能にします。すでに冒頭で述べたようにしかし、既存のクライアントは、すでに彼らが関心のある各メールボックスのSTATUSコマンドの多数を生成することであることをやろう。メールボックスの大きなリストのステータス情報の検索を実行している間、サーバーの実装は必要なときに、それはまだ、他の接続に他の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.

この文書では、LIST-STATUSのIMAP機能を定義します。 IANAは、レジストリに追加しました。

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

IANAはまた、[LISTEXT]によって確立されたIANAレジストリに次の新しいLIST-EXTENDEDオプションを追加しました：

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

To：iana@iana.org件名：LIST-EXTENDEDオプションのSTATUSの登録

LIST-EXTENDED option name: STATUS

LIST-EXTENDEDオプション名：STATUS

LIST-EXTENDED option type: RETURN

LIST-EXTENDEDオプションタイプ：RETURN

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

LIST-EXTENDEDオプションの説明：LIST応答に加えて、STATUS応答を返すためにLISTコマンドを引き起こします。

Published specification: RFC 5819

公開された仕様：RFC 5819

Security considerations: RFC 5819

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

Intended usage: COMMON

意図している用法：COMMON

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

Personと詳細のために連絡する電子メールアドレス：アレクセイ・メルニコフ<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.

STATUSおよびLISTコマンドは、往復の交通と数を最適化するために組み合わせるべきであると指摘したフィリップ・ヴァン・フーフに感謝します。

8. Normative References

8.引用規格

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

、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、エド、およびP. Overell、。。

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

[ACL]メルニコフ、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.メルニコフ、 "インターネットメッセージアクセスプロトコルバージョン4 - LISTコマンドの拡張機能"、RFC 5258、2008年6月。

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

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

Authors' Addresses

著者のアドレス

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

アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国

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

電子メール：Alexey.Melnikov@isode.com URI：http://www.melnikov.ca/

Timo Sirainen

ティモ・シレーヌン

EMail: tss@iki.fi

メールアドレス：tss@iki.fi