[要約] RFC 5258は、IMAPバージョン4のLISTコマンドの拡張に関するものであり、目的はIMAPサーバーがサポートするメールボックスのリストをクライアントに提供することです。
Network Working Group B. Leiba
Request for Comments: 5258 IBM T.J. Watson Research Center
Obsoletes: 3348 A. Melnikov
Updates: 2193 Isode Limited
Category: Standards Track June 2008
Internet Message Access Protocol version 4 - LIST Command Extensions
インターネットメッセージアクセスプロトコルバージョン4-リストコマンド拡張機能
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands.
IMAP4には、メールボックスをリストするための2つのコマンドがあります：リストとLSUB。各拡張機能がリストとLSUBの両方にその関数を追加する必要があり、これらのコマンドは定義されているため、リストコマンドの数を拡張する必要がありました。、拡張可能。一緒に動作するために拡張機能が必要な場合は、さまざまなオプションを組み合わせるために一連のコマンドを追加する必要がありました。セットは、新しい拡張機能ごとにサイズが増加します。このドキュメントでは、これらの追加をリストコマンドに相互に互換性のあるオプションで実行できるようにするベースリストコマンドへの拡張機能について説明します。
Table of Contents
目次
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Extended LIST Command . . . . . . . . . . . . . . . . . . . . 4
3.1. Initial List of Selection Options . . . . . . . . . . . . 7
3.2. Initial List of Return Options . . . . . . . . . . . . . . 8
3.3. General Principles for Returning LIST Responses . . . . . 9
3.4. Additional Requirements on LIST-EXTENDED Clients . . . . . 9
3.5. CHILDINFO Extended Data Item . . . . . . . . . . . . . . . 10
4. The CHILDREN Return Option . . . . . . . . . . . . . . . . . . 11
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Internationalization Considerations . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. Guidelines for IANA . . . . . . . . . . . . . . . . . . . 23
9.2. Registration Procedure and Change Control . . . . . . . . 23
9.3. Registration Template for LIST-EXTENDED Options . . . . . 25
9.4. Initial LIST-EXTENDED Option Registrations . . . . . . . . 25
9.5. Registration Template for LIST-EXTENDED Extended Data
Item . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.6. Initial LIST-EXTENDED Extended Data Item Registrations . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 30
The LIST command is extended by amending the syntax to allow options and multiple patterns to be specified. The list of options replaces the several commands that are currently used to mix and match the information requested. The new syntax is backward compatible, with no ambiguity: the new syntax is being used if one of the following conditions is true:
リストコマンドは、構文を修正してオプションと複数のパターンを指定できるようにすることで拡張されます。オプションのリストは、要求された情報を混合して一致させるために現在使用されているいくつかのコマンドを置き換えます。新しい構文は、あいまいさのない後方互換性があります。次の条件のいずれかが真である場合、新しい構文が使用されています。
1. if the first word after the command name begins with a parenthesis ("LIST selection options")
1. コマンド名の後の最初の単語が括弧で始まる場合（「選択オプション」）
2. if the second word after the command name begins with a parenthesis ("multiple mailbox patterns")
2. コマンド名の後の2番目の単語が括弧で始まる場合（「複数のメールボックスパターン」）
3. if the LIST command has more than 2 parameters ("LIST return options")
3. Listコマンドに2つ以上のパラメーターがある場合（ "list return options"）
Otherwise the original syntax is used.
それ以外の場合は、元の構文が使用されます。
By adding options to the LIST command, we are announcing the intent to phase out and eventually to deprecate the RLIST and RLSUB commands described in [MBRef]. We are also defining the mechanism to request extended mailbox information, such as is described in the Child Mailbox Extension [CMbox]. The base LSUB command is not deprecated by this extension; rather, this extension adds a way to obtain subscription information with more options, with those server implementations that support it. Clients that simply need a list of subscribed mailboxes, as provided by the LSUB command, SHOULD continue to use that command.
リストコマンドにオプションを追加することにより、[MBREF]で説明されているRLISTおよびRLSUBコマンドを廃止する意図を発表します。また、Child Mailbox Extension [CMBOX]に記載されているような、拡張されたメールボックス情報を要求するメカニズムを定義しています。ベースLSUBコマンドは、この拡張機能によって非推奨されません。むしろ、この拡張機能は、より多くのオプションを備えたサブスクリプション情報を取得する方法を追加し、それをサポートするサーバーの実装を使用します。LSUBコマンドが提供するように、購読されたメールボックスのリストを単に必要とするクライアントは、そのコマンドを引き続き使用する必要があります。
This document defines an IMAP4 extension that is identified by the capability string "LIST-EXTENDED". The LIST-EXTENDED extension makes the following changes to the IMAP4 protocol, which are described in more detail in Section 3 and Section 4:
このドキュメントは、機能文字列「リスト拡張」によって識別されるIMAP4拡張機能を定義します。リスト拡張拡張機能は、次の変更をIMAP4プロトコルに変更します。これは、セクション3およびセクション4で詳細に説明されています。
a. defines new syntax for LIST command options.
a. リストコマンドオプションの新しい構文を定義します。
b. extends LIST to allow for multiple mailbox patterns.
b. リストを拡張して、複数のメールボックスパターンを可能にします。
c. adds LIST command selection options: SUBSCRIBED, REMOTE, and RECURSIVEMATCH.
c. リストコマンドの選択オプションを追加：購読、リモート、およびrecursivematch。
d. adds LIST command return options: SUBSCRIBED and CHILDREN.
d. リストコマンドリターンオプションを追加：購読および子供。
e. adds new mailbox attributes: "\NonExistent", "\Subscribed", "\Remote", "\HasChildren", and "\HasNoChildren".
e. 新しいメールボックスの属性を追加します： "\ nonexistent"、 "\ subscribed"、 "\ remote"、 "\ haschildren"、および "\ hasnochildren"。
f. adds CHILDINFO extended data item.
f. ChildInfo拡張データ項目を追加します。
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", "SHOULD", "SHOULD NOT", and "MAY" are used in this document as specified in RFC 2119 [Kwds].
キーワードは、「必須」、「必要はない」、「ははや」、「必要はありません」、および「可能な」、および「可能な」、RFC 2119 [KWDS]で指定されているこのドキュメントで使用されます。
The term "canonical LIST pattern" refers to the canonical pattern constructed internally by the server from the reference and mailbox name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command returns only mailboxes that match the canonical LIST pattern.
「標準リストパターン」という用語は、参照およびメールボックス名の引数（[IMAP4]のセクション6.3.8）からサーバーによって内部的に構築された標準パターンを指します。[IMAP4]リストコマンドは、標準リストパターンに一致するメールボックスのみを返します。
Other terms are introduced where they are referenced for the first time.
他の用語が初めて参照される場所で導入されます。
This extension updates the syntax of the LIST command to allow for multiple mailbox patterns to be specified, if they are enclosed in parentheses. A mailbox name matches a list of mailbox patterns if it matches at least one mailbox pattern. If a mailbox name matches multiple mailbox patterns from the list, the server SHOULD return only a single LIST response.
この拡張機能は、括弧内に囲まれている場合、複数のメールボックスパターンを指定できるように、リストコマンドの構文を更新します。メールボックス名は、少なくとも1つのメールボックスパターンと一致する場合、メールボックスパターンのリストと一致します。メールボックス名がリストから複数のメールボックスパターンと一致する場合、サーバーは単一のリスト応答のみを返す必要があります。
Note that the non-extended LIST command is required to treat an empty ("" string) mailbox name argument as a special request to return the hierarchy delimiter and the root name of the name given in the reference parameter (as per [IMAP4]). However, ANY extended LIST command (extended in any of 3 ways specified in Section 1, or any combination thereof) MUST NOT treat the empty mailbox name as such a special request, and any regular processing described in this document applies. In particular, if an extended LIST command has multiple mailbox names and one (or more) of them is the empty string, the empty string MUST be ignored for the purpose of matching.
空の（ "" string）メールボックス名の引数を、階層デリミッターと参照パラメーターに与えられた名前のルート名を返すための特別な要求として扱うには、拡張されていないリストコマンドが必要であることに注意してください（[IMAP4]に従って）。ただし、拡張リストコマンド（セクション1で指定された3つの方法のいずれか、またはその任意の組み合わせのいずれかで拡張）は、空のメールボックス名をそのような特別なリクエストとして扱うべきではなく、このドキュメントに記載されている定期的な処理が適用されます。特に、拡張リストコマンドに複数のメールボックス名があり、それらの1つ（またはそれ以上）が空の文字列である場合、一致する目的で空の文字列を無視する必要があります。
Some servers might restrict which patterns are allowed in a LIST command. If a server doesn't accept a particular pattern, it MUST silently ignore it.
一部のサーバーは、リストコマンドで許可されるパターンを制限する場合があります。サーバーが特定のパターンを受け入れない場合、静かに無視する必要があります。
The LIST command syntax is also extended in two additional ways: by adding a parenthesized list of command options between the command name and the reference name (LIST selection options) and an optional list of options at the end that control what kind of information should be returned (LIST return options). See the formal syntax in Section 6 for specific details.
リストコマンドの構文は、コマンド名と参照名（リスト選択オプション）の間に括弧付きのコマンドオプションのリストを追加することにより、2つの追加方法で拡張されます。返された（リストリターンオプション）。特定の詳細については、セクション6の正式な構文を参照してください。
A LIST selection option tells the server which mailbox names should be selected by the LIST operation. The server should return information about all mailbox names that match any of the "canonical LIST pattern" (as described above) and satisfy additional selection criteria (if any) specified by the LIST selection options. Let's call any such mailbox name a "matched mailbox name". When multiple selection options are specified, the server MUST return information about mailbox names that satisfy every selection option, unless a description of a particular specified option prescribes special rules. An example of an option prescribing special rules is the RECURSIVEMATCH selection option described later in this section. We will use the term "selection criteria" when referring collectively to all selection options specified in a LIST command.
リスト選択オプションは、リスト操作によってどのメールボックス名を選択するかをサーバーに伝えます。サーバーは、「標準リストパターン」（上記のように）のいずれかに一致するすべてのメールボックス名に関する情報を返し、リストの選択オプションで指定された追加の選択基準（もしあれば）を満たす必要があります。そのようなメールボックス名を「一致したメールボックス名」と呼びましょう。複数の選択オプションが指定されている場合、特定の指定されたオプションの説明が特別なルールを規定していない限り、サーバーはすべての選択オプションを満たすメールボックス名に関する情報を返す必要があります。特別なルールを規定するオプションの例は、このセクションで後述する再sursivematch選択オプションです。リストコマンドで指定されたすべての選択オプションを集合的に参照する場合、「選択基準」という用語を使用します。
A LIST return option controls which information is returned for each matched mailbox name. Note that return options MUST NOT cause the server to report information about additional mailbox names. If the client has not specified any return option, only information about attributes should be returned by the server. (Of course, the server is allowed to include any other information at will.)
リストリターンオプションは、一致したメールボックス名ごとに返される情報を制御します。返品オプションにより、サーバーが追加のメールボックス名に関する情報を報告してはならないことに注意してください。クライアントが返品オプションを指定していない場合、サーバーによって属性に関する情報のみを返す必要があります。（もちろん、サーバーは他の情報を自由に含めることができます。）
Both selection and return command options will be defined in this document and in approved extension documents; each option will be enabled by a capability string (one capability may enable multiple options), and a client MUST NOT send an option for which the server has not advertised support. A server MUST respond to options it does not recognize with a BAD response. The client SHOULD NOT specify any option more than once; however, if the client does this, the server MUST act as if it received the option only once. The order in which options are specified by the client is not significant.
選択および返信コマンドオプションの両方が、このドキュメントと承認された拡張ドキュメントで定義されます。各オプションは、機能文字列（1つの機能が複数のオプションを有効にする場合があります）で有効になり、クライアントはサーバーがサポートを宣伝していないオプションを送信してはなりません。サーバーは、悪い応答で認識されないオプションに応答する必要があります。クライアントは、オプションを複数回指定してはなりません。ただし、クライアントがこれを行う場合、サーバーは1回だけオプションを受信したかのように動作する必要があります。クライアントがオプションを指定する順序は重要ではありません。
In general, each selection option except RECURSIVEMATCH will have a corresponding return option. The REMOTE selection option is an anomaly in this regard, and does not have a corresponding return option. That is because it expands, rather than restricts, the set of mailboxes that are returned. Future extensions to this specification should keep parallelism in mind and define a pair of corresponding options.
一般に、RecurSiveMatchを除く各選択オプションには、対応する返品オプションがあります。リモート選択オプションは、この点で異常であり、対応する返品オプションはありません。それは、返されるメールボックスのセットを制限するのではなく、拡張するためです。この仕様の将来の拡張は、並列性を念頭に置いて、対応する一対のオプションを定義する必要があります。
This extension is identified by the capability string "LIST-EXTENDED", and support for it is a prerequisite for any future extensions that require specialized forms of the LIST command. Such extensions MUST refer to this document and MUST add their function through command options as described herein. Note that extensions that don't require support for an extended LIST command, but use extended LIST responses (see below), don't need to advertise the "LIST-EXTENDED" capability string.
この拡張機能は、機能文字列「リスト拡張」によって識別され、それに対するサポートは、リストコマンドの特殊なフォームを必要とする将来の拡張機能の前提条件です。このような拡張機能は、このドキュメントを参照する必要があり、本書に記載されているようにコマンドオプションを介して機能を追加する必要があります。拡張リストコマンドのサポートを必要としないが、拡張リスト応答（以下を参照）を使用する拡張機能は、「リスト拡張」機能文字列を宣伝する必要はないことに注意してください。
This extension also defines extensions to the LIST response, allowing a series of extended fields at the end, a parenthesized list of tagged data (also referred to as "extended data item"). The first element of an extended field is a tag, which identifies the type of data. Tags MUST be registered with IANA, as described in Section 9.5 of this document. An example of such an extended set might be
この拡張機能は、リスト応答への拡張機能も定義し、最後に一連の拡張フィールドを許可します。タグ付きデータの括弧付きリスト（「拡張データ項目」とも呼ばれます）。拡張フィールドの最初の要素はタグで、データのタイプを識別します。このドキュメントのセクション9.5で説明されているように、タグはIANAに登録する必要があります。このような拡張セットの例はあるかもしれません
tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text"))
テーブルクロス（（ "edge" "lacy"）（ "color" "red"））（xサンプル "テキスト"）））））
or
また
tablecloth ("edge" "lacy")) (X-Sample "text" "more text"))
テーブルクロス（ "edge" "lacy"））（x-sample "text" "more text"）））
See the formal syntax, in Section 6, for the full syntactic details. The server MUST NOT return any extended data item unless the client has expressed its ability to support extended LIST responses, for example, by using an extended LIST command. The server MAY return data in the extended fields that was not directly solicited by the client in the corresponding LIST command. For example, the client can enable extra extended fields by using another IMAP extension that make use of the extended LIST responses. The client MUST ignore all extended fields it doesn't recognize.
完全な構文の詳細については、セクション6の正式な構文を参照してください。クライアントが拡張リストの応答をサポートする機能を表明していない限り、サーバーは拡張データ項目を返してはなりません。サーバーは、対応するリストコマンドでクライアントが直接勧誘されなかった拡張フィールドのデータを返すことができます。たとえば、クライアントは、拡張リスト応答を使用する別のIMAP拡張機能を使用して、追加の拡張フィールドを有効にすることができます。クライアントは、認識されていないすべての拡張フィールドを無視する必要があります。
The LIST-EXTENDED capability also defines several new mailbox attributes.
リスト拡張機能は、いくつかの新しいメールボックス属性も定義します。
The "\NonExistent" attribute indicates that a mailbox name does not refer to an existing mailbox. Note that this attribute is not meaningful by itself, as mailbox names that match the canonical LIST pattern but don't exist must not be returned unless one of the two conditions listed below is also satisfied:
「\ nowing」属性は、メールボックス名が既存のメールボックスを参照していないことを示します。標準リストパターンに一致するが、存在しないメールボックス名は、以下にリストされている2つの条件のいずれかも満たされない限り、返さないでください。
a. The mailbox name also satisfies the selection criteria (for example, it is subscribed and the "SUBSCRIBED" selection option has been specified).
a. メールボックス名は選択基準も満たしています（たとえば、サブスクライブされ、「サブスクライブ」選択オプションが指定されています）。
b. "RECURSIVEMATCH" has been specified, and the mailbox name has at least one descendant mailbox name that does not match the LIST pattern and does match the selection criteria.
b. 「recursivematch」が指定されており、メールボックス名には、リストパターンと一致せず、選択基準と一致する少なくとも1つの子孫のメールボックス名があります。
In practice, this means that the "\NonExistent" attribute is usually returned with one or more of "\Subscribed", "\Remote", "\HasChildren", or the CHILDINFO extended data item (see their description below).
実際には、これは、「\ nountistent」属性が通常、1つ以上の「\ subscribed」、「\ remote」、「\ haschildren」、またはchildinfo拡張データ項目で返されることを意味します（以下の説明を参照）。
The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" attribute MUST be supported and MUST be accurately computed.
「\非存在」属性は、「\ noselect」を意味します。「\非存在」属性をサポートする必要があり、正確に計算する必要があります。
The selection options defined in this specification are as follows:
この仕様で定義されている選択オプションは次のとおりです。
SUBSCRIBED - causes the LIST command to list subscribed names, rather than the existing mailboxes. This will often be a subset of the actual mailboxes. It's also possible for this list to contain the names of mailboxes that don't exist. In any case, the list MUST include exactly those mailbox names that match the canonical list pattern and are subscribed to. This option is intended to supplement the LSUB command. Of particular note are the mailbox attributes as returned by this option, compared with what is returned by LSUB. With the latter, the attributes returned may not reflect the actual attribute status on the mailbox name, and the \NoSelect attribute has a second special meaning (it indicates that this mailbox is not, itself, subscribed, but that it has descendant mailboxes that are). With the SUBSCRIBED selection option described here, the attributes are accurate and complete, and have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, and some servers must do significant extra work to respond to "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue to use "LSUB" unless they specifically want the additional information offered by "LIST (SUBSCRIBED)".
登録 - 既存のメールボックスではなく、List Commandが購読された名前をリストします。これは、多くの場合、実際のメールボックスのサブセットになります。また、このリストが存在しないメールボックスの名前を含めることもできます。いずれにせよ、リストには、標準リストパターンに一致し、サブスクライブされるメールボックス名を正確に含める必要があります。このオプションは、LSUBコマンドを補足することを目的としています。特に注目すべきは、LSUBによって返されるものと比較して、このオプションによって返されるメールボックス属性です。後者の場合、返される属性は、メールボックス名の実際の属性ステータスを反映していない場合があり、\ noselect属性には2番目の特別な意味があります（このメールボックスはそれ自体ではなく、購読されていないが、それは子孫のメールボックスがあることを示します。）。ここで説明されているサブスクライブ選択オプションを使用すると、属性は正確で完全であり、特別な意味はありません。したがって、「lsub」と「list（subscribed）」は同じものではなく、一部のサーバーは「リスト（購読）」に応答するために重要な追加作業を行う必要があります。このため、クライアントは「LSUB」を使用し続ける必要があります。「LSUB」は、「リスト（購読）」で提供される追加情報を具体的に望んでいます。
This option defines a new mailbox attribute, "\Subscribed", that indicates that a mailbox name is subscribed to. The "\Subscribed" attribute MUST be supported and MUST be accurately computed when the SUBSCRIBED selection option is specified.
このオプションは、新しいメールボックス属性「\ subscribed」を定義します。これは、メールボックス名がサブスクライブされていることを示します。「\ Subscribed」属性をサポートする必要があり、サブスクライブ選択オプションが指定されている場合は正確に計算する必要があります。
Note that the SUBSCRIBED selection option implies the SUBSCRIBED return option (see below).
購読された選択オプションは、購読された返品オプションを意味することに注意してください（以下を参照）。
REMOTE - causes the LIST command to show remote mailboxes as well as local ones, as described in [MBRef]. This option is intended to replace the RLIST command and, in conjunction with the SUBSCRIBED selection option, the RLSUB command.
リモート - [MBREF]に記載されているように、List Commandにリモートメールボックスとローカルメールボックスが表示されます。このオプションは、RLISTコマンドを置き換え、登録済み選択オプションと併せてRLSUBコマンドを置き換えることを目的としています。
This option defines a new mailbox attribute, "\Remote", that indicates that a mailbox is a remote mailbox. The "\Remote" attribute MUST be accurately computed when the REMOTE option is specified.
このオプションは、メールボックスがリモートメールボックスであることを示す新しいメールボックス属性「\ remote」を定義します。「\ remote」属性は、リモートオプションが指定されているときに正確に計算する必要があります。
The REMOTE selection option has no interaction with other options. Its effect is to tell the server to apply the other options, if any, to remote mailboxes, in addition to local ones. In particular, it has no interaction with RECURSIVEMATCH (see below). A request for (REMOTE RECURSIVEMATCH) is invalid, because a request for (RECURSIVEMATCH) is. A request for (REMOTE RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes, both local and remote.
リモート選択オプションには、他のオプションとのやり取りがありません。その効果は、ローカルのオプションに加えて、他のオプションをリモートメールボックスに適用するようにサーバーに指示することです。特に、recursivematchとの相互作用はありません（以下を参照）。（recursivematch）のリクエストは、（remote recursivematch）の要求は無効です。（リモートRecursivematchのサブスクライブ）のリクエストは、ローカルとリモートの両方のサブスクライブされたすべてのメールボックスを求めています。
RECURSIVEMATCH - this option forces the server to return information about parent mailboxes that don't match other selection options, but have some submailboxes that do. Information about children is returned in the CHILDINFO extended data item, as described in Section 3.5.
recursivematch-このオプションは、他の選択オプションと一致しないが、いくつかのサブメールボックスを持っている親メールボックスに関する情報をサーバーに返すように強制します。セクション3.5で説明されているように、子どもに関する情報は、ChildInfo拡張データ項目に返されます。
Note 1: In order for a parent mailbox to be returned, it still has to match the canonical LIST pattern.
注1：親メールボックスを返すためには、標準リストパターンと一致する必要があります。
Note 2: When returning the CHILDINFO extended data item, it doesn't matter whether or not the submailbox matches the canonical LIST pattern. See also example 9 in Section 5.
注2：ChildInfo拡張データ項目を返すとき、サブメールボックスが標準リストパターンと一致するかどうかは関係ありません。セクション5の例9も参照してください。
The RECURSIVEMATCH option MUST NOT occur as the only selection option (or only with REMOTE), as it only makes sense when other selection options are also used. The server MUST return BAD tagged response in such case.
recursivematchオプションは、他の選択オプションも使用される場合にのみ意味があるため、唯一の選択オプションとして（またはリモートのみ）発生してはなりません。サーバーは、そのような場合に悪いタグ付き応答を返す必要があります。
Note that even if the RECURSIVEMATCH option is specified, the client MUST still be able to handle a case when a CHILDINFO extended data item is returned and there are no submailboxes that meet the selection criteria of the subsequent LIST command, as they can be deleted/renamed after the LIST response was sent, but before the client had a chance to access them.
recursivematchオプションが指定されている場合でも、ChildInfo拡張データ項目が返され、後続のListコマンドの選択基準を満たすサブメールボックスが削除できない場合、クライアントはまだケースを処理できる必要があります。リストの応答が送信された後に変更されましたが、クライアントがアクセスする機会がありました。
The return options defined in this specification are as follows:
この仕様で定義されている返品オプションは次のとおりです。
SUBSCRIBED - causes the LIST command to return subscription state for all matching mailbox names. The "\Subscribed" attribute MUST be supported and MUST be accurately computed when the SUBSCRIBED return option is specified. Further, all mailbox flags MUST be accurately computed (this differs from the behavior of the LSUB command).
購読 - 一致するすべてのメールボックス名に対して、リストコマンドがサブスクリプション状態を返します。「\ subscribed」属性をサポートする必要があり、サブスクライブされた戻りオプションが指定されたときに正確に計算する必要があります。さらに、すべてのメールボックスフラグを正確に計算する必要があります（これはLSUBコマンドの動作とは異なります）。
CHILDREN - requests mailbox child information as originally proposed in [CMbox]. See Section 4, below, for details. This option MUST be supported by all servers.
子供 - [cmbox]で最初に提案されたメールボックスの子情報を要求します。詳細については、以下のセクション4を参照してください。このオプションは、すべてのサーバーでサポートする必要があります。
This section outlines several principles that can be used by server implementations of this document to decide whether a LIST response should be returned, as well as how many responses and what kind of information they may contain.
このセクションでは、このドキュメントのサーバー実装で使用できるいくつかの原則を概説して、リストの応答を返すべきかどうか、どのような回答とそれらに含まれる情報の種類を決定するかを決定します。
1. At most one LIST response should be returned for each mailbox name that matches the canonical LIST pattern. Server implementors must not assume that clients will be able to assemble mailbox attributes and other information returned in multiple LIST responses.
1. 最大で1つのリスト応答は、標準リストパターンに一致する各メールボックス名に対して返される必要があります。サーバーの実装者は、クライアントが複数のリスト応答で返されるメールボックス属性やその他の情報を組み立てることができると想定してはなりません。
2. There are only two reasons for including a matching mailbox name in the responses to the LIST command (note that the server is allowed to return unsolicited responses at any time, and such responses are not governed by this rule):
2. リストコマンドへの応答に一致するメールボックス名を含める理由は2つしかありません（サーバーはいつでも未承諾の応答を返すことが許可されており、そのような応答はこのルールに準拠していません）：
A. The mailbox name also satisfies the selection criteria.
A.メールボックス名は、選択基準も満たしています。
B. The mailbox name doesn't satisfy the selection criteria, but it has at least one descendant mailbox name that satisfies the selection criteria and that doesn't match the canonical LIST pattern.
B.メールボックス名は選択基準を満たしていませんが、選択基準を満たし、標準リストパターンと一致しない少なくとも1つの子孫メールボックス名があります。
For more information on this case, see the CHILDINFO extended data item described in Section 3.5. Note that the CHILDINFO extended data item can only be returned when the RECURSIVEMATCH selection option is specified.
このケースの詳細については、セクション3.5で説明したChildInfo拡張データ項目を参照してください。ChildInfo拡張データ項目は、recursivematch選択オプションが指定されている場合にのみ返すことができることに注意してください。
3. Attributes returned in the same LIST response must be treated additively. For example, the following response
3. 同じリスト応答で返された属性は、添加的に扱う必要があります。たとえば、次の回答
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
s： * list（\ subscribed \ nonexistent） "/" "フルーツ/ピーチ"
means that the "Fruit/Peach" mailbox doesn't exist, but it is subscribed.
「フルーツ/ピーチ」メールボックスは存在しないが、購読されていることを意味します。
All clients that support this extension MUST treat an attribute with a stronger meaning as implying any attribute that can be inferred from it. For example, the client must treat the presence of the \NoInferiors attribute as if the \HasNoChildren attribute was also sent by the server.
この拡張機能をサポートするすべてのクライアントは、属性をより強力な意味で扱う必要があります。たとえば、クライアントは、\ hasnochildren属性もサーバーによって送信されたかのように、\ noinferiors属性の存在を扱う必要があります。
The following table summarizes inference rules described in Section 3.
次の表は、セクション3で説明されている推論ルールをまとめたものです。
+--------------------+-------------------+
| returned attribute | implied attribute |
+--------------------+-------------------+
| \NoInferiors | \HasNoChildren |
| \NonExistent | \NoSelect |
+--------------------+-------------------+
The CHILDINFO extended data item MUST NOT be returned unless the client has specified the RECURSIVEMATCH selection option.
ChildInfo拡張データ項目は、クライアントが再usivematch選択オプションを指定していない限り、返品しないでください。
The CHILDINFO extended data item in a LIST response describes the selection criteria that has caused it to be returned and indicates that the mailbox has at least one descendant mailbox that matches the selection criteria.
List ResponseのChildInfo拡張データ項目は、それを返した原因となった選択基準を説明し、メールボックスに選択基準に一致する少なくとも1つの子孫メールボックスがあることを示します。
The LSUB command indicates this condition by using the "\NoSelect" attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since "\NoSelect" retains its original meaning here. Further, the CHILDINFO extended data item is more general, in that it can be used with any extended set of selection criteria.
lsubコマンドは、「\ noselect」属性を使用してこの条件を示しますが、「\ noselect」はここで元の意味を保持するため、リスト（登録）コマンドはそれを行うべきではありません。さらに、ChildInfo拡張データ項目は、拡張された一連の選択基準とともに使用できるという点で、より一般的です。
Note: Some servers allow for mailboxes to exist without requiring their parent to exist. For example, a mailbox "Customers/ABC" can exist while the mailbox "Customers" does not. As CHILDINFO extended data item is not allowed if the RECURSIVEMATCH selection option is not specified, such servers SHOULD use the "\NonExistent \HasChildren" attribute pair to signal to the client that there is a descendant mailbox that matches the selection criteria. See example 11 in Section 5.
注：一部のサーバーでは、親が存在することを要求することなく、メールボックスを存在させることができます。たとえば、メールボックス「顧客/ABC」は存在し、メールボックス「顧客」には存在しません。ChildInfo拡張データ項目は許可されていないため、recursivematch選択オプションが指定されていない場合、そのようなサーバーは「\ nonexistent \ haschildren」属性ペアを使用して、選択基準に一致する子孫のメールボックスがあることをクライアントに信号する必要があります。セクション5の例11を参照してください。
The returned selection criteria allow the client to distinguish a solicited response from an unsolicited one, as well as to distinguish among solicited responses caused by multiple pipelined LIST commands that specify different criteria.
返された選択基準により、クライアントは勧誘された応答を未承諾の応答と区別し、異なる基準を指定する複数のパイプラインリストコマンドによって引き起こされる勧誘された応答を区別することができます。
Servers SHOULD ONLY return a non-matching mailbox name along with CHILDINFO if at least one matching child is not also being returned. That is, servers SHOULD suppress redundant CHILDINFO responses.
サーバーは、少なくとも1人の一致する子供も返されない場合は、ChildInfoと一緒に一致しないメールボックス名とのみを返す必要があります。つまり、サーバーは冗長なChildINFO応答を抑制する必要があります。
Examples 8 and 10 in Section 5 demonstrate the difference between present CHILDINFO extended data item and the "\HasChildren" attribute.
セクション5の例8と10は、現在のChildInfo拡張データ項目と「\ haschildren」属性の違いを示しています。
The following table summarizes interaction between the "\NonExistent" attribute and CHILDINFO (the first column indicates whether the parent mailbox exists):
次の表には、「\ nounexistent」属性とChildInfoの相互作用を要約します（最初の列は、親メールボックスが存在するかどうかを示します）。
+--------+--------------+--------------------+----------------------+
| exists | meets the | has a child that | returned |
| | selection | meets the | LIST-EXTENDED |
| | criteria | selection criteria | attributes and |
| | | | CHILDINFO |
+--------+--------------+--------------------+----------------------+
| no | no | no | no LIST response |
| | | | returned |
| yes | no | no | no LIST response |
| | | | returned |
| no | yes | no | (\NonExistent |
| | | | <attr>) |
| yes | yes | no | (<attr>) |
| no | no | yes | (\NonExistent) + |
| | | | CHILDINFO |
| yes | no | yes | () + CHILDINFO |
| no | yes | yes | (\NonExistent |
| | | | <attr>) + CHILDINFO |
| yes | yes | yes | (<attr>) + CHILDINFO |
+--------+--------------+--------------------+----------------------+
where <attr> is one or more attributes that correspond to the selection criteria; for example, for the SUBSCRIBED option the <attr> is \Subscribed.
ここで、<attr>は、選択基準に対応する1つ以上の属性です。たとえば、サブスクライブオプションの場合、<attr>は\サブスクライブされます。
The CHILDREN return option implements the Child Mailbox Extension, originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft Corporation. Most of the information in this section is taken directly from their original specification [CMbox]. The CHILDREN return option is simply an indication that the client wants this information; a server MAY provide it even if the option is not specified.
子供のリターンオプションは、Microsoft CorporationのMike GahrnsとRaymond Chengが元々提案したChild Mailbox Extensionを実装しています。このセクションのほとんどの情報は、元の仕様[CMBOX]から直接取得されます。子供の戻りオプションは、クライアントがこの情報を望んでいることを示すものです。サーバーは、オプションが指定されていなくても提供される場合があります。
Many IMAP4 [IMAP4] clients present to the user a hierarchical view of the mailboxes that a user has access to. Rather than initially presenting to the user the entire mailbox hierarchy, it is often preferable to show to the user a collapsed outline list of the mailbox hierarchy (particularly if there is a large number of mailboxes). The user can then expand the collapsed outline hierarchy as needed. It is common to include within the collapsed hierarchy a visual clue (such as a ''+'') to indicate that there are child mailboxes under a particular mailbox. When the visual clue is clicked, the hierarchy list is expanded to show the child mailboxes. The CHILDREN return option provides a mechanism for a client to efficiently determine whether a particular mailbox has children, without issuing a LIST "" * or a LIST "" % for each mailbox name. The CHILDREN return option defines two new attributes that MUST be returned within a LIST response: \HasChildren and \HasNoChildren. Although these attributes MAY be returned in response to any LIST command, the CHILDREN return option is provided to indicate that the client particularly wants this information. If the CHILDREN return option is present, the server MUST return these attributes even if their computation is expensive.
多くのIMAP4 [IMAP4]クライアントは、ユーザーがアクセスできるメールボックスの階層ビューをユーザーに提示します。メールボックス階層全体を最初に提示するよりも、メールボックス階層の崩壊したアウトラインリストをユーザーに表示することが望ましいことがよくあります（特に多数のメールボックスがある場合）。ユーザーは、必要に応じて崩壊したアウトライン階層を拡張できます。崩壊した階層内に、特定のメールボックスの下に子供のメールボックスがあることを示すために、視覚的な手がかり（ '' ''など）を含めることが一般的です。視覚的な手がかりがクリックされると、階層リストが拡張され、子メールボックスが表示されます。Children Returnオプションは、クライアントが、各メールボックス名のリスト「 *またはリスト」％を発行せずに、特定のメールボックスに子供がいるかどうかを効率的に決定するメカニズムを提供します。Children Return Optionは、リスト応答内で返さなければならない2つの新しい属性を定義します。これらの属性は、任意のリストコマンドに応じて返される場合がありますが、クライアントがこの情報を特に望んでいることを示すために、子供の返品オプションが提供されます。子供が戻っているオプションが存在する場合、計算が高価であっても、サーバーはこれらの属性を返す必要があります。
\HasChildren
\ haschildren
The presence of this attribute indicates that the mailbox has child mailboxes. A server SHOULD NOT set this attribute if there are child mailboxes and the user does not have permission to access any of them. In this case, \HasNoChildren SHOULD be used. In many cases, however, a server may not be able to efficiently compute whether a user has access to any child mailbox. Note that even though the \HasChildren attribute for a mailbox must be correct at the time of processing of the mailbox, a client must be prepared to deal with a situation when a mailbox is marked with the \HasChildren attribute, but no child mailbox appears in the response to the LIST command. This might happen, for example, due to children mailboxes being deleted or made inaccessible to the user (using access control) by another client before the server is able to list them.
この属性の存在は、メールボックスにチャイルドメールボックスがあることを示しています。子のメールボックスがある場合、ユーザーがそれらのいずれかにアクセスする許可がない場合、サーバーはこの属性を設定しないでください。この場合、\ hasnochildrenを使用する必要があります。ただし、多くの場合、サーバーは、ユーザーが子供のメールボックスにアクセスできるかどうかを効率的に計算できない場合があります。メールボックスの\ haschildren属性は、メールボックスの処理時に正しいものでなければなりませんが、メールボックスに\ haschildren属性がマークされている場合、クライアントは状況に対処するために準備する必要がありますが、子供のメールボックスが表示されないことに注意してください。リストコマンドへの応答。これは、たとえば、子供のメールボックスが削除されるか、ユーザーが他のクライアントがユーザーがアクセスできなくなっているために発生する可能性があります。
\HasNoChildren
\ hasnochildren
The presence of this attribute indicates that the mailbox has NO child mailboxes that are accessible to the currently authenticated user.
この属性の存在は、メールボックスに現在認証されているユーザーがアクセスできる子メールボックスがないことを示しています。
It is an error for the server to return both a \HasChildren and a \HasNoChildren attribute in the same LIST response.
サーバーが同じリスト応答で\ haschildrenと\ hasnochildren属性の両方を返すことはエラーです。
Note: the \HasNoChildren attribute should not be confused with the IMAP4 [IMAP4] defined attribute \NoInferiors, which indicates that no child mailboxes exist now and none can be created in the future.
注：\ hasnoChildren属性は、IMAP4 [IMAP4]定義された属性\ noinferiorsと混同しないでください。
1: The first example shows the complete local hierarchy that will be used for the other examples.
1：最初の例は、他の例に使用される完全なローカル階層を示しています。
C: A01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST () "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST () "/" "Vegetable"
S: * LIST () "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: A01 OK done
2: In the next example, we will see the subscribed mailboxes. This is similar to, but not equivalent with, <LSUB "" "*">. Note that the mailbox called "Fruit/Peach" is subscribed to, but does not actually exist (perhaps it was deleted while still subscribed). The "Fruit" mailbox is not subscribed to, but it has two subscribed children. The "Vegetable" mailbox is subscribed and has two children; one of them is subscribed as well.
2：次の例では、購読されたメールボックスが表示されます。これは、<lsub "" "*">に似ていますが、同等ではありません。「Fruit/Peach」と呼ばれるメールボックスはサブスクライブされていますが、実際には存在しません（おそらく、登録中に削除された可能性があります）。「フルーツ」メールボックスは購読されていませんが、2人の購読された子供がいます。「野菜」メールボックスには購読されており、2人の子供がいます。そのうちの1つも購読されています。
C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: A02 OK done
3: The next example shows the use of the CHILDREN option. The client, without having to list the second level of hierarchy, now knows which of the top-level mailboxes have submailboxes (children) and which do not. Note that it's not necessary for the server to return the \HasNoChildren attribute for the inbox, because the \NoInferiors attribute already implies that, and has a stronger meaning.
3：次の例は、子供のオプションの使用を示しています。クライアントは、階層の第2レベルをリストすることなく、どのトップレベルのメールボックスにサブメールボックス（子供）があり、どれがそうでないかがわかりました。\ noinferiors属性はすでにそれを暗示し、より強い意味を持っているため、サーバーが受信トレイの\ hasnochildren属性を返す必要はないことに注意してください。
C: A03 LIST () "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: A03 OK done
4: In this example, we see more mailboxes that reside on another server. This is similar to the command <RLIST "" "%">.
4：この例では、別のサーバーに存在するメールボックスが増えています。これは、コマンド<rlist "" "％">に似ています。
C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done
5: The following example also requests the server to include mailboxes that reside on another server. The server returns information about all mailboxes that are subscribed. This is similar to the command <RLSUB "" "*">. We also see the use of two selection options.
5：次の例では、サーバーに別のサーバーに存在するメールボックスを含めるように要求します。サーバーは、購読されているすべてのメールボックスに関する情報を返します。これは、コマンド<rlsub "" "*">に似ています。また、2つの選択オプションが使用されています。
C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: A05 OK done
6: The following example requests the server to include mailboxes that reside on another server. The server is asked to return subscription information for all returned mailboxes. This is different from the example above.
6：次の例では、サーバーに別のサーバーに存在するメールボックスを含めるように要求します。サーバーは、返されたすべてのメールボックスのサブスクリプション情報を返すように求められます。これは、上記の例とは異なります。
Note that the output of this command is not a superset of the output in the previous example, as it doesn't include LIST response for the non-existent "Fruit/Peach".
このコマンドの出力は、存在しない「フルーツ/ピーチ」のリスト応答が含まれていないため、前の例の出力のスーパーセットではないことに注意してください。
C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: * LIST (\Remote) "/" "Meat"
S: A06 OK done
7: In the following example, the client has specified multiple mailbox patterns. Note that this example does not use the mailbox hierarchy used in the previous examples.
7：次の例では、クライアントは複数のメールボックスパターンを指定しています。この例は、前の例で使用されたメールボックス階層を使用していないことに注意してください。
C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
S: * LIST () "/" "INBOX"
S: * LIST (\NoInferiors) "/" "Drafts"
S: * LIST () "/" "Sent/March2004"
S: * LIST (\Marked) "/" "Sent/December2003"
S: * LIST () "/" "Sent/August2004"
S: BBB OK done
8: The following example demonstrates the difference between the \HasChildren attribute and the CHILDINFO extended data item.
8：次の例は、\ haschildren属性とChildInfo拡張データ項目の違いを示しています。
Let's assume there is the following hierarchy:
次の階層があると仮定しましょう。
C: C01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Foo"
S: * LIST () "/" "Foo/Bar"
S: * LIST () "/" "Foo/Baz"
S: * LIST () "/" "Moo"
S: C01 OK done
If the client asks RETURN (CHILDREN), it will get this:
クライアントが戻って（子供）に尋ねた場合、それはこれを取得します：
C: CA3 LIST "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Foo"
S: * LIST (\HasNoChildren) "/" "Moo"
S: CA3 OK done
A) Let's also assume that the mailbox "Foo/Baz" is the only subscribed mailbox. Then we get this result:
a）メールボックス「foo/baz」が唯一の購読されているメールボックスであると仮定しましょう。次に、この結果が得られます。
C: C02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "Foo/Baz"
S: C02 OK done
Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server will return no mailboxes (as the mailboxes "Moo", "Foo", and "Inbox" are NOT subscribed). However, if the client issues this:
これで、クライアントが<list（subscribed） "" "％">を発行した場合、サーバーはメールボックスを返さない（メールボックス「MOO」、「FOO」、および「受信トレイ」がサブスクライブされないように）。ただし、クライアントがこれを発行した場合：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
(i.e., the mailbox "Foo" is not subscribed, but it has a child that is.)
（つまり、メールボックス「foo」は購読されていませんが、子供がいます。）
A1) If the mailbox "Foo" had also been subscribed, the last command would return this:
a1）メールボックス「foo」も購読されていた場合、最後のコマンドはこれを返します。
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
or even this:
またはこれでさえ：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO"
("SUBSCRIBED"))
S: C04 OK done
A2) If we assume instead that the mailbox "Foo" is not part of the original hierarchy and is not subscribed, the last command will give this result:
a2）代わりに、メールボックス「foo」が元の階層の一部ではなく、サブスクライブされていないと想定した場合、最後のコマンドは次の結果を与えます。
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
B) Now, let's assume that no mailbox is subscribed. In this case, the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will return no responses, as there are no subscribed children (even though "Foo" has children).
b）ここで、メールボックスが購読されていないと仮定しましょう。この場合、command <list（subscribed recursivematch） "" ""％ "は、サブスクライブされた子供がいないため、応答を返しません（「foo」には子供がいますが）。
C) And finally, suppose that only the mailboxes "Foo" and "Moo" are subscribed. In that case, we see this result:
c）そして最後に、メールボックスの「foo」と「MOO」のみが購読されていると仮定します。その場合、この結果がわかります。
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done
(which means that the mailbox "Foo" has children, but none of them is subscribed).
（つまり、メールボックス「foo」には子供がいますが、どれも購読されていません）。
9: The following example demonstrates that the CHILDINFO extended data item is returned whether or not children mailboxes match the canonical LIST pattern.
9：次の例は、子供のメールボックスが標準リストパターンと一致するかどうかにかかわらず、ChildInfo拡張データ項目が返されることを示しています。
Let's assume there is the following hierarchy:
次の階層があると仮定しましょう。
C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2"
S: * LIST () "/" "baz2"
S: * LIST () "/" "baz2/bar2"
S: * LIST () "/" "baz2/bar22"
S: * LIST () "/" "baz2/bar222"
S: * LIST () "/" "eps2"
S: * LIST () "/" "eps2/mamba"
S: * LIST () "/" "qux2/bar2"
S: D01 OK done
And that the following mailboxes are subscribed:
そして、次のメールボックスがサブスクライブされていること：
C: D02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2"
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D02 OK done
The client issues the following command first:
クライアントは最初に次のコマンドを発行します。
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done
and the server may also include (but this would violate a SHOULD NOT in Section 3.5, because CHILDINFO is redundant)
また、サーバーには含まれる場合があります（ただし、ChildInfoが冗長であるため、セクション3.5ではこれに違反します）
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
The CHILDINFO extended data item is returned for mailboxes "foo2", "baz2", and "eps2", because all of them have subscribed children, even though for the mailbox "foo2" only one of the two subscribed children matches the pattern, for the mailbox "baz2" all the subscribed children match the pattern, and for the mailbox "eps2" none of the subscribed children matches the pattern.
ChildInfo拡張データ項目は、メールボックス「FOO2」、「BAZ2」、および「EPS2」のメールボックスに返されます。すべての人が子供をサブスクライブしているためです。メールボックス「baz2」サブスクライブされたすべての子供はパターンと一致し、メールボックス「eps2」については、サブスクライブされた子供はどれもパターンに一致していません。
Note that if the client issues
クライアントが発行した場合に注意してください
C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done
The LIST responses for mailboxes "foo2", "baz2", and "eps2" still have the CHILDINFO extended data item, even though this information is redundant and the client can determine it by itself.
この情報は冗長であり、クライアントがそれを単独で決定できるにもかかわらず、メールボックス「Foo2」、「Baz2」、および「EPS2」のリストの応答には、ChildInfo拡張データ項目がまだあります。
10: The following example shows usage of multiple mailbox patterns. It also demonstrates that the presence of the CHILDINFO extended data item doesn't necessarily imply \HasChildren.
10：次の例は、複数のメールボックスパターンの使用法を示しています。また、ChildInfo拡張データ項目の存在が必ずしも\ haschildrenを意味するわけではないことを示しています。
C: a1 LIST "" ("foo" "foo/*")
S: * LIST () "/" foo
S: a1 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: a3 OK done
11: The following example shows how a server that supports missing mailbox hierarchy elements can signal to a client that didn't specify the RECURSIVEMATCH selection option that there is a child mailbox that matches the selection criteria.
11：次の例は、欠落しているメールボックスの階層要素をサポートするサーバーが、選択基準に一致する子メールボックスがあることをrecursivematch選択オプションを指定しなかったクライアントにどのように信号を送ることができるかを示しています。
C: a1 LIST (REMOTE) "" *
S: * LIST () "/" music/rock
S: * LIST (\Remote) "/" also/jazz
S: a1 OK done
C: a2 LIST () "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: a2 OK done
C: a3 LIST (REMOTE) "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: * LIST (\NonExistent \HasChildren) "/" also
S: a3 OK done
C: a3.1 LIST "" (% music/rock)
S: * LIST () "/" music/rock
S: a3.1 OK done
Because "music/rock" is the only mailbox under "music", there's no need for the server to also return "music". However clients must handle both cases.
「Music/Rock」は「Music」の下の唯一のメールボックスであるため、サーバーが「音楽」も返す必要はありません。ただし、クライアントは両方のケースを処理する必要があります。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [ABNF]. Terms not defined here are taken from [IMAP4]. In particular, note that the version of "mailbox-list" below, which defines the payload of the LIST response, updates the version defined in the IMAP specification. It is pointed to by "mailbox-data", which is defined in [IMAP4].
次の構文仕様では、[ABNF]で説明されているように、拡張されたバックスノーフォーム（ABNF）を使用します。ここで定義されていない用語は[IMAP4]から取得されます。特に、リスト応答のペイロードを定義する「メールボックスリスト」のバージョンは、IMAP仕様で定義されたバージョンを更新することに注意してください。[IMAP4]で定義されている「Mailbox-Data」によって指摘されています。
"vendor-token" is defined in [ACAP]. Note that this normative reference to ACAP will be an issue in moving this spec forward, since it introduces a dependency on ACAP. The definitions of "vendor-token" and of the IANA registry must eventually go somewhere else, in a document that can be moved forward on the standards track independently of ACAP.
「ベンダートークン」は[ACAP]で定義されています。ACAPへのこの規範的な参照は、ACAPへの依存性を導入するため、この仕様を前進させる問題になることに注意してください。「ベンダートークン」とIANAレジストリの定義は、ACAPとは無関係に標準トラックで前進できるドキュメントで、最終的にどこか別の場所に行かなければなりません。
childinfo-extended-item = "CHILDINFO" SP "("
list-select-base-opt-quoted
*(SP list-select-base-opt-quoted) ")"
; Extended data item (mbox-list-extended-item)
; returned when the RECURSIVEMATCH
; selection option is specified.
; Note 1: the CHILDINFO tag can be returned
; with and without surrounding quotes, as per
; mbox-list-extended-item-tag production.
; Note 2: The selection options are always returned
; quoted, unlike their specification in
; the extended LIST command.
child-mbox-flag = "\HasChildren" / "\HasNoChildren"
; attributes for CHILDREN return option, at most one
; possible per LIST response
eitem-standard-tag = atom ; a tag for extended list data defined in a Standard ; Track or Experimental RFC.
eitem-standard-tag = atom;標準で定義された拡張リストデータのタグ。トラックまたは実験RFC。
eitem-vendor-tag = vendor-token "-" atom ; a vendor-specific tag for extended list data
eitem-vendor-tag = vendor-token " - " atom;拡張リストデータのベンダー固有のタグ
list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat [SP list-return-opts]
list = "list" [sp list-select-opts] sp mailbox sp mbox-or-pat [sp list-return-opts]
list-return-opts = "RETURN" SP "(" [return-option *(SP return-option)] ")" ; list return options, e.g., CHILDREN
list-return-opts = "return" sp "（" [return-option *（sp return-option）] "）";リターンオプション、たとえば子供をリストします
list-select-base-opt = "SUBSCRIBED" / option-extension ; options that can be used by themselves
list-select-base-opt = "subscribed" / option-extension;自分で使用できるオプション
list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
list-select-independent-opt = "REMOTE" / option-extension ; options that do not syntactically interact with ; other options
List-Select-Indepent-Opt = "Remote" / option-Extension;構文的に対話しないオプション。その他のオプション
list-select-mod-opt = "RECURSIVEMATCH" / option-extension ; options that require a list-select-base-opt ; to also be present
list-select-mod-opt = "recursivematch" / option-extension;リスト選択ベースOPTを必要とするオプション。存在することもあります
list-select-opt = list-select-base-opt / list-select-independent-opt / list-select-mod-opt ; An option registration template is described in ; Section 9.3 of this document.
list-select-opt = list-select-base-opt / list-select-bendepent-opt / list-select-mod-opt;オプション登録テンプレートはで説明されています。このドキュメントのセクション9.3。
list-select-opts = "(" [
(*(list-select-opt SP) list-select-base-opt
*(SP list-select-opt))
/ (list-select-independent-opt
*(SP list-select-independent-opt))
] ")"
; Any number of options may be in any order.
; If a list-select-mod-opt appears, then a
; list-select-base-opt must also appear.
; This allows these:
; ()
; (REMOTE)
; (SUBSCRIBED)
; (SUBSCRIBED REMOTE)
; (SUBSCRIBED RECURSIVEMATCH)
; (SUBSCRIBED REMOTE RECURSIVEMATCH)
; But does NOT allow these:
; (RECURSIVEMATCH)
; (REMOTE RECURSIVEMATCH)
mailbox-list = "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox [SP mbox-list-extended] ; This is the list information pointed to by the ABNF ; item "mailbox-data", which is defined in [IMAP4]
MailBox-List = "（" [mbx-list-flags] "）" sp（dquote quoted-char dquote / nil）sp mailbox [sp mbox-list-extended];これは、ABNFが指摘したリスト情報です。[IMAP4]で定義されているアイテム「Mailbox-Data」
mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")"
mbox-list-extended = "（" [mbox-list-extended-item *（sp mbox-list-extended-item） "）"
mbox-list-extended-item = mbox-list-extended-item-tag SP tagged-ext-val
mbox-list-extended-item = mbox-list-extend-exted-item-tag sp tagged-ext-val
mbox-list-extended-item-tag = astring
; The content MUST conform to either "eitem-vendor-tag"
; or "eitem-standard-tag" ABNF productions.
; A tag registration template is described in this
; document in Section 9.5.
mbx-list-oflag =/ child-mbox-flag / "\Subscribed" / "\Remote"
mbx-list-sflag =/ "\NonExistent"
mbx-list-sflag =/ "\ nexistent"
mbox-or-pat = list-mailbox / patterns
option-extension = (option-standard-tag / option-vendor-tag)
[SP option-value]
option-standard-tag = atom ; an option defined in a Standards Track or ; Experimental RFC
option-standard-tag = atom;標準トラックで定義されているオプションまたは実験RFC
option-val-comp = astring /
option-val-comp *(SP option-val-comp) /
"(" option-val-comp ")"
option-value = "(" option-val-comp ")"
option-value = "（" option-val-comp "）"
option-vendor-tag = vendor-token "-" atom ; a vendor-specific option, non-standard
option-vendor-tag = vendor-token " - " atom;ベンダー固有のオプション、非標準
patterns = "(" list-mailbox *(SP list-mailbox) ")"
return-option = "SUBSCRIBED" / "CHILDREN" / option-extension
tagged-ext-comp = astring /
tagged-ext-comp *(SP tagged-ext-comp) /
"(" tagged-ext-comp ")"
; Extensions that follow this general
; syntax should use nstring instead of
; astring when appropriate in the context
; of the extension.
; Note that a message set or a "number"
; can always be represented as an "atom".
; A URL should be represented as
; a "quoted" string.
tagged-ext-simple = sequence-set / number
tagged-ext-val = tagged-ext-simple / "(" [tagged-ext-comp] ")"
Tagged-ext-val = tagged-ext-simple / "（" [tagged-ext-comp] "）"
The LIST command selection option types defined in this specification involve simple tests of mailbox properties. However, future extensions to LIST-EXTENDED may define selection options that do more sophisticated tests. In the case of a test that requires matching text, in the presence of the COMPARATOR [I18N] extension, the active comparator must be used to do comparisons. Such LIST-EXTENDED extensions MUST indicate in their specification the interaction with the COMPARATOR [I18N] extension.
この仕様で定義されているリストコマンド選択オプションタイプには、メールボックスプロパティの簡単なテストが含まれます。ただし、将来のリスト拡張は、より洗練されたテストを行う選択オプションを定義する場合があります。一致するテキストを必要とするテストの場合、コンパレータ[i18n]拡張が存在する場合、有効コンパレータを使用して比較する必要があります。このようなリスト拡張拡張機能は、仕様において、コンパレータ[I18N]拡張との相互作用を示す必要があります。
This document describes syntactic changes to the specification of the IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST command has the same security considerations as those commands. They are described in [IMAP4] and [MBRef].
このドキュメントでは、IMAP4コマンドリスト、LSUB、RLIST、およびRLSUBの仕様に対する構文の変更について説明し、修正リストコマンドはそれらのコマンドと同じセキュリティ上の考慮事項を持っています。[IMAP4]および[MBREF]で説明されています。
The Child Mailbox Extension provides a client a more efficient means of determining whether a particular mailbox has children. If a mailbox has children, but the currently authenticated user does not have access to any of them, the server SHOULD respond with a \HasNoChildren attribute. In many cases, however, a server may not be able to efficiently compute whether a user has access to any child mailbox. If such a server responds with a \HasChildren attribute, when in fact the currently authenticated user does not have access to any child mailboxes, potentially more information is conveyed about the mailbox than intended. In most situations, this will not be a security concern, because if information regarding whether a mailbox has children is considered sensitive, a user would not be granted access to that mailbox in the first place.
Child Mailbox Extensionは、特定のメールボックスに子供がいるかどうかを判断するためのより効率的な手段をクライアントに提供します。メールボックスには子供がいるが、現在認証されているユーザーがそれらのいずれにもアクセスできない場合、サーバーは\ hasnochildren属性で応答する必要があります。ただし、多くの場合、サーバーは、ユーザーが子供のメールボックスにアクセスできるかどうかを効率的に計算できない場合があります。このようなサーバーが\ haschildren属性で応答する場合、実際に認証されているユーザーが子供のメールボックスにアクセスできない場合、潜在的に、意図したよりも多くの情報がメールボックスについて伝えられます。ほとんどの状況では、これはセキュリティの懸念ではありません。メールボックスに子供がいるかどうかに関する情報が敏感であると見なされる場合、ユーザーはそもそもそのメールボックスへのアクセスを許可されないからです。
The CHILDINFO extended data item has the same security considerations as the \HasChildren attribute described above.
ChildInfo拡張データ項目は、上記の\ haschildren属性と同じセキュリティ上の考慮事項を持っています。
IANA has created two new registries for LIST-EXTENDED options and LIST-EXTENDED response data. The templates and the initial registrations are detailed below.
IANAは、リスト拡張オプションとリスト拡張された応答データの2つの新しいレジストリを作成しました。テンプレートと初期登録については、以下に詳しく説明します。
Registration of a LIST-EXTENDED option is done by filling in the template in Section 9.3 and sending it via electronic mail to iana@iana.org. Registration of a LIST-EXTENDED extended data item is done by filling in the template in Section 9.5 and sending it via electronic mail to iana@iana.org. IANA has the right to reject obviously bogus registrations, but will perform no review of claims made in the registration form.
リスト拡張オプションの登録は、セクション9.3のテンプレートに記入し、電子メールでiana@iana.orgに送信することにより行われます。リストが拡張された拡張データ項目の登録は、セクション9.5のテンプレートに記入し、電子メールでiana@iana.orgに送信することにより行われます。IANAには明らかに偽の登録を拒否する権利がありますが、登録フォームで行われた請求のレビューは行われません。
A LIST-EXTENDED option/extended data item name that starts with "V-" is reserved for vendor-specific options/extended data items. All options, whether they are vendor specific or global, should be registered with IANA. If a LIST-EXTENDED extended data item is returned as a result of requesting a particular LIST-EXTENDED option, the name of the option SHOULD be used as the name of the LIST-EXTENDED extended data item.
「V-」から始まるリスト拡張オプション/拡張データアイテム名は、ベンダー固有のオプション/拡張データ項目に予約されています。ベンダー固有であろうとグローバルであろうと、すべてのオプションはIANAに登録する必要があります。特定のリスト拡張オプションを要求した結果として、リスト拡張拡張データ項目が返される場合、オプションの名前は、リスト拡張拡張データ項目の名前として使用する必要があります。
Each vendor-specific option/extended data item MUST start with its vendor-token ("vendor prefix"). The vendor-token MUST be registered with IANA, using the [ACAP] vendor subtree registry.
各ベンダー固有のオプション/拡張データ項目は、ベンダートークン（「ベンダープレフィックス」）から開始する必要があります。ベンダートークンは、[ACAP]ベンダーサブツリーレジストリを使用して、IANAに登録する必要があります。
Standard LIST-EXTENDED option/extended data item names are case insensitive. If the vendor prefix is omitted from a vendor-specific LIST-EXTENDED option/extended data item name, the rest is case insensitive. The vendor prefix itself is not case sensitive, as it might contain non-ASCII characters. While the registration procedures do not require it, authors of LIST-EXTENDED options/extended data items are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an Internet-Draft. LIST-EXTENDED option/extended data items intended for widespread use should be standardized through the normal IETF process, when appropriate.
標準のリスト拡張オプション/拡張データ項目名は、ケースの無感覚です。ベンダー固有のリスト拡張オプション/拡張データアイテム名からベンダーのプレフィックスが省略されている場合、残りはケースでは鈍感です。ベンダーのプレフィックス自体は、ASCII以外の文字が含まれている可能性があるため、ケースに敏感ではありません。登録手順ではそれを必要としませんが、リストが拡張されたオプション/拡張データ項目の著者は、それが実行可能なときはいつでもコミュニティのレビューとコメントを求めることが奨励されます。著者は、提案されたメカニズムの指定をインターネットドラフトとして投稿することにより、コミュニティのレビューを求めることができます。必要に応じて、広範囲に使用するためのリスト拡張オプション/拡張データ項目は、通常のIETFプロセスを通じて標準化する必要があります。
Comments on registered LIST-EXTENDED options/extended response data should first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG mailing list. Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the registration itself. If IANA approves of this, the comment will be made accessible in conjunction with the registration LIST-EXTENDED options/extended response data itself.
登録されたリスト拡張オプション/拡張応答データに関するコメントは、最初にメカニズムの「所有者」および/またはIMAPEXT WGメーリングリストに送信する必要があります。コメントの提出者は、所有者に連絡する合理的な試みの後、IANAに登録自体にコメントを添付するよう要求する場合があります。IANAがこれを承認した場合、コメントは登録リスト拡張オプション/拡張応答データ自体と併せてアクセス可能になります。
Once a LIST-EXTENDED registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request.
リストが拡張された登録がIANAによって公開されると、著者はその定義の変更を要求することができます。変更要求は、登録要求と同じ手順に従います。
The owner of a LIST-EXTENDED registration may pass responsibility for the registered option/extended data item to another person or agency by informing IANA; this can be done without discussion or review.
リストが拡張された登録の所有者は、IANAに通知することにより、登録オプション/拡張データ項目の責任を他の人または代理店に渡すことができます。これは、議論やレビューなしで行うことができます。
The IESG may reassign responsibility for a LIST-EXTENDED option/extended data item. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community.
IESGは、リスト拡張オプション/拡張データ項目の責任を再割り当てする場合があります。これの最も一般的なケースは、登録の著者が死亡した、接触しなくなった、またはコミュニティにとって重要な変更を加えることができないメカニズムに変更を加えることを可能にすることです。
LIST-EXTENDED registrations may not be deleted; mechanisms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field. Such LIST-EXTENDED options/extended data items will be clearly marked in the lists published by IANA.
リストが拡張された登録は削除されない場合があります。使用に適していないと考えられているメカニズムは、「意図した使用」フィールドの変更により、時代遅れと宣言できます。このようなリスト拡張オプション/拡張データ項目は、IANAが公開したリストに明確にマークされます。
The IESG is considered to be the owner of all LIST-EXTENDED options/extended data items that are on the IETF standards track.
IESGは、IETF標準トラックにあるすべてのリスト拡張オプション/拡張データ項目の所有者であると考えられています。
To: iana@iana.org Subject: Registration of LIST-EXTENDED option X
宛先：iana@iana.org件名：リスト拡張オプションxの登録
LIST-EXTENDED option name:
リスト拡張オプション名：
LIST-EXTENDED option type: (One of SELECTION or RETURN)
リスト拡張オプションタイプ：（選択または返品の1つ）
Implied return options(s), if the option type is SELECTION: (zero or more)
オプションタイプが選択の場合、暗黙の返品オプション（s）：（ゼロ以上）
LIST-EXTENDED option description:
リスト拡張オプション説明：
Published specification (optional, recommended):
公開された仕様（オプション、推奨）：
Security considerations:
セキュリティ上の考慮事項：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図された使用法：（一般的な使用、限られた使用、または時代遅れの1つ）
Person and email address to contact for further information:
詳細については、人とメールアドレスをお問い合わせください。
Owner/Change controller:
所有者/変更コントローラー：
(Any other information that the author deems interesting may be added below this line.)
（著者が興味深いと思うその他の情報は、この行の下に追加される場合があります。）
The LIST-EXTENDED option registry has been populated with the following entries:
リスト拡張オプションレジストリには、次のエントリが入力されています。
1. To: iana@iana.org Subject: Registration of LIST-EXTENDED option SUBSCRIBED
1. 宛先：iana@iana.org件名：リスト拡張オプションの登録サブスクライブ
LIST-EXTENDED option name: SUBSCRIBED
リスト拡張オプション名：購読
LIST-EXTENDED option type: SELECTION
リスト拡張オプションタイプ：選択
Implied return options(s): SUBSCRIBED
暗黙の返品オプション：購読
LIST-EXTENDED option description: Causes the LIST command to list subscribed mailboxes, rather than the actual mailboxes.
リスト拡張オプション説明：実際のメールボックスではなく、リストコマンドが購読されたメールボックスをリストします。
Published specification: RFC 5258, Section 3.
公開された仕様：RFC 5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティ上の考慮事項：RFC 5258、セクション8。
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
2. To: iana@iana.org Subject: Registration of LIST-EXTENDED option REMOTE
2. 宛先：iana@iana.org件名：リスト拡張オプションの登録リモート
LIST-EXTENDED option name: REMOTE
リスト拡張オプション名：リモート
LIST-EXTENDED option type: SELECTION
リスト拡張オプションタイプ：選択
Implied return options(s): (none)
暗黙の返品オプション：（なし）
LIST-EXTENDED option description: Causes the LIST command to return remote mailboxes as well as local ones, as described in RFC 2193.
リスト拡張オプション説明：RFC 2193で説明されているように、Listコマンドはリモートメールボックスとローカルメールボックスを返します。
Published specification: RFC 5258, Section 3.
公開された仕様：RFC 5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティ上の考慮事項：RFC 5258、セクション8。
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
3. To: iana@iana.org Subject: Registration of LIST-EXTENDED option SUBSCRIBED
3. 宛先：iana@iana.org件名：リスト拡張オプションの登録サブスクライブ
LIST-EXTENDED option name: SUBSCRIBED
リスト拡張オプション名：購読
LIST-EXTENDED option type: RETURN
リスト拡張オプションタイプ：返品
LIST-EXTENDED option description: Causes the LIST command to return subscription state.
リスト拡張オプション説明：リストコマンドがサブスクリプション状態を返します。
Published specification: RFC 5258, Section 3.
公開された仕様：RFC 5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティ上の考慮事項：RFC 5258、セクション8。
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
4. To: iana@iana.org Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH
4. 宛先：iana@iana.org件名：リスト拡張オプションの登録recursivematch
LIST-EXTENDED option name: RECURSIVEMATCH
リスト拡張オプション名：recursivematch
LIST-EXTENDED option type: SELECTION
リスト拡張オプションタイプ：選択
Implied return options(s): (none)
暗黙の返品オプション：（なし）
LIST-EXTENDED option description: Requests that CHILDINFO extended data item (childinfo-extended-item) is to be returned.
リスト拡張オプション説明：ChildInfo拡張データ項目（ChildInfo-Extended-Item）が返されることを要求します。
Published specification: RFC 5258, Section 3.
公開された仕様：RFC 5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティ上の考慮事項：RFC 5258、セクション8。
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
5. To: iana@iana.org Subject: Registration of LIST-EXTENDED option CHILDREN
5. 宛先：iana@iana.org件名：リスト拡張オプションの子供の登録
LIST-EXTENDED option name: CHILDREN
リスト拡張オプション名：子供
LIST-EXTENDED option type: RETURN
リスト拡張オプションタイプ：返品
LIST-EXTENDED option description: Requests mailbox child information.
リスト拡張オプション説明：メールボックスの子情報を要求します。
Published specification: RFC 5258, Section 3 and Section 4.
公開された仕様：RFC 5258、セクション3、セクション4。
Security considerations: RFC 5258, Section 8.
セキュリティ上の考慮事項：RFC 5258、セクション8。
Intended usage: COMMON
意図された使用法：共通
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: iesg@ietf.org
To: iana@iana.org Subject: Registration of X LIST-EXTENDED extended data item
宛先：iana@iana.org件名：xリスト拡張拡張データ項目の登録
LIST-EXTENDED extended data item tag:
リスト拡張拡張データ項目タグ：
LIST-EXTENDED extended data item description:
リスト拡張拡張データ項目説明：
Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any):
リスト拡張オプション（およびその種類）により、この拡張データ項目が返されます（もしあれば）：
Published specification (optional, recommended):
公開された仕様（オプション、推奨）：
Security considerations:
セキュリティ上の考慮事項：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図された使用法：（一般的な使用、限られた使用、または時代遅れの1つ）
Person and email address to contact for further information:
詳細については、人とメールアドレスをお問い合わせください。
Owner/Change controller:
所有者/変更コントローラー：
(Any other information that the author deems interesting may be added below this line.)
（著者が興味深いと思うその他の情報は、この行の下に追加される場合があります。）
The LIST-EXTENDED extended data item registry has been populated with the following entries:
リストが拡張された拡張データアイテムレジストリには、次のエントリが入力されています。
1. To: iana@iana.org Subject: Registration of CHILDINFO LIST-EXTENDED extended data item
1. 宛先：iana@iana.org件名：childinfoリスト拡張データ項目の登録
LIST-EXTENDED extended data item tag: CHILDINFO
リスト拡張拡張データ項目タグ：ChildInfo
LIST-EXTENDED extended data item description: The CHILDINFO extended data item describes the selection criteria that has caused it to be returned and indicates that the mailbox has one or more child mailboxes that match the selection criteria.
リストが拡張された拡張データ項目説明：ChildInfo拡張データ項目は、それを返した原因となった選択基準を説明し、メールボックスに選択基準と一致する1つ以上の子メールボックスがあることを示します。
Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any): RECURSIVEMATCH selection option Published specification: RFC 5258, Section 3.5.
リスト拡張オプション（およびその種類）により、この拡張データ項目が返されます（存在する場合）：recursivematch選択オプション公開された仕様：RFC 5258、セクション3.5。
Security considerations: RFC 5258, Section 8.
セキュリティ上の考慮事項：RFC 5258、セクション8。
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
Mike Gahrns and Raymond Cheng of Microsoft Corporation originally devised the Child Mailbox Extension and proposed it in 1997; the idea, as well as most of the text in Section 4, is theirs.
Microsoft CorporationのMike GahrnsとRaymond Chengは、元々Child Mailbox拡張機能を考案し、1997年に提案しました。アイデアとセクション4のテキストのほとんどは、彼らのものです。
This document is the result of discussions on the IMAP4 and IMAPEXT mailing lists and is meant to reflect consensus of those groups. In particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry Greenfield, Dave Cridland, and Pete Maclean were active participants in those discussions or made suggestions to this document.
このドキュメントは、IMAP4およびIMAPEXTメーリングリストに関する議論の結果であり、これらのグループのコンセンサスを反映することを目的としています。特に、マーク・クリスピン、フィリップ・ギャンテル、サイラス・ダブー、ティモ・シライネン、ケン・マーチソン、ロブ・シエンボルスキー、スティーブ・ホール、アルント・ガルブランドセン、ラリー・グリーンフィールド、デイブ・クリッドランド、およびピート・マクリーンは、これらの議論またはこの文書への提案の積極的な参加者でした。
[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月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[i18n] Newman、C.、Gulbrandsen、A。、およびA. Melnikov、「インターネットメッセージアクセスプロトコル国際化」、RFC 5255、2008年6月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[KWDS] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September 1997.
[Mbref] Gahrns、M。、「IMAP4 Mailbox Referrals」、RFC 2193、1997年9月。
[CMbox] Gahrns, M. and R. Cheng, "The Internet Message Action Protocol (IMAP4) Child Mailbox Extension", RFC 3348, July 2002.
[CMBOX] Gahrns、M。およびR. Cheng、「インターネットメッセージアクションプロトコル（IMAP4）チャイルドメールボックス拡張機能」、RFC 3348、2002年7月。
Authors' Addresses
著者のアドレス
Barry Leiba IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
バリー・レイバIBM T.J.ワトソンリサーチセンター19スカイラインドライブホーソーン、ニューヨーク10532米国
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
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/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。