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 - LISTコマンドの拡張機能
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.
LISTとLSUB：IMAP4はメールボックスを一覧表示するための2つのコマンドがあります。我々は専門のリストを必要としている、そのようなメールボックスの紹介などの拡張機能を、追加したように、各拡張子はLISTとLSUBの両方にその機能を追加する必要がありますので、我々は、listコマンドの数を拡大しなければならなかった、そしてそれらが定義されているように、これらのコマンドは、ありません、拡張可能。私たちが一緒に動作するように拡張を必要とした場合、我々はさまざまなオプション、それぞれの新しい拡張子を持つ大型化セットを混合するためにコマンドのセットを追加しなければなりませんでした。この文書は、専門listコマンドの指数関数的な増加を避け、これらの追加は、LISTコマンドに対して相互に互換性のオプションで行うことを可能にする基本LISTコマンドの拡張機能について説明しています。
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:
LISTコマンドはオプションと複数のパターンを指定できるようにするための構文を修正することによって拡張されます。オプションのリストには、現在要求された情報をミックスして一致させるために使用されているいくつかのコマンドを置き換えます。新しい構文はあいまいで、下位互換性があり、次の条件のいずれかに該当する場合、新しい構文が使用されています：
1. if the first word after the command name begins with a parenthesis ("LIST selection options")
1.コマンド名の後の最初の単語が括弧で始まる場合（「LIST選択オプション」）
2. if the second word after the command name begins with a parenthesis ("multiple mailbox patterns")
2.コマンド名の後の第二の単語は、括弧（「複数のメールボックスのパターン」）で始まる場合
3. if the LIST command has more than 2 parameters ("LIST return options")
3. LISTコマンドは、2つの以上のパラメータ（「LISTリターンオプション」）を持っている場合
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.
LISTコマンドのオプションを追加することで、我々は段階的に廃止する意図を発表しているし、最終的には[MBRef]で説明RLISTとRLSUBコマンドを廃止します。我々はまた、子供のメールボックス拡張[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:
この文書では、機能文字列「LIST-EXTENDED」で識別されるIMAP4の拡張子を定義します。 LIST拡張拡張は、第3及び第4節でより詳細に記載されているIMAP4プロトコルに以下の変更を行います。
a. defines new syntax for LIST command options.
A。 LISTコマンドのオプションの新しい構文を定義します。
b. extends LIST to allow for multiple mailbox patterns.
B。複数のメールボックスのパターンを可能にするためにリストを拡張します。
c. adds LIST command selection options: SUBSCRIBED, REMOTE, and RECURSIVEMATCH.
C。加入し、REMOTE、およびRECURSIVEMATCH：LISTコマンドの選択オプションが追加されます。
d. adds LIST command return options: SUBSCRIBED and CHILDREN.
D。 LISTコマンドの戻りオプションを追加します。加入してCHILDREN。
e. adds new mailbox attributes: "\NonExistent", "\Subscribed", "\Remote", "\HasChildren", and "\HasNoChildren".
電子。 "\の存在しない"、 "\購読済み"、 "\リモート"、 "\ 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].
キーワード "MUST"、 "MUST NOT"、 "SHOULD"、 "SHOULD NOT"、およびRFC 2119 [Kwds]で指定されるように、このドキュメントで使用されている "MAY"。
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.
用語「カノニカルLISTパターン」は、参照とメールボックス名引数（[IMAP4]のセクション6.3.8）からサーバによって内部で構築正規パターンを指します。 [IMAP4] LISTコマンドが正規LISTパターンに一致するメールボックスのみを返します。
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.
この拡張は、彼らが括弧で囲まれている場合は、指定する複数のメールボックスのパターンを可能にするためにLISTコマンドの構文を更新します。それは、少なくとも1つのメールボックスのパターンと一致した場合に、メールボックス名は、メールボックスのパターンのリストと一致しました。メールボックス名がリストから複数のメールボックスのパターンと一致した場合、サーバーは、単一のLIST応答を返すべきです。
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.
非拡張LISTコマンドは階層デリミタを返す特別な要求と（[IMAP4]の通り）参照パラメータで指定された名前のルート名として空（「」の文字列）メールボックス名引数を治療するために必要であることに注意してください。しかし、（第1、またはそれらの任意の組み合わせで指定された3つのいずれかの方法で拡張）ANY拡張LISTコマンドは、このような特殊な要求として、空のメールボックス名を扱うてはならない、と本書に記載された任意の通常の処理が適用されます。具体的には、拡張リストコマンドは、それら複数のメールボックス名と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.
一部のサーバーはLISTコマンドで許可されているパターン制限される場合があります。サーバが特定のパターンを受け入れない場合、それは黙ってそれを無視しなければなりません。
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.
LISTコマンドの構文は、2つの付加的な方法で拡張されている：情報の種類がどうあるべきかを制御コマンド名と参照名（リスト選択オプション）、最後にオプションのオプションのリスト間のコマンドオプションの括弧リストを追加することによって返された（LISTリターンオプション）。具体的な詳細については、セクション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.
LIST選択オプションは、メールボックス名は、LIST操作で選択する必要があり、サーバーに指示します。サーバーは「正規LISTパターン」のいずれかに一致するすべてのメールボックス名についての情報を返します（上記の通り）と（もしあれば）LIST選択オプションで指定された追加の選択基準を満たす必要があります。のは、そのようなメールボックス名「マッチしたメールボックス名」と呼ぶことにしましょう。複数の選択オプションが指定されている場合、サーバーは、特定の指定されたオプションの説明は特別な規則を定めていない限り、すべての選択オプションを満たすメールボックス名に関する情報を返さなければなりません。特別なルールを規定するオプションの例は、このセクションで後述RECURSIVEMATCH選択オプションです。 LISTコマンドで指定されたすべての選択オプションをまとめて参照するとき私たちは、用語「選択基準」を使用します。
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.)
情報が一致した各メールボックス名のために返されるLISTリターンを制御します。リターンオプションは、サーバーが追加のメールボックス名に関する情報を報告するために引き起こしてはならないことに注意してください。クライアントは任意のリターンオプションを指定しなかった場合、属性に関する情報のみがサーバから返されなければなりません。 （もちろん、サーバーは自由に他の任意の情報を含むことが許されます。）
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つの機能は、複数のオプションを有効にする）機能文字列で有効になり、クライアントは、サーバがサポートして広告しなかったためのオプションを送ってはいけません。サーバはBAD応答と認識していないオプションに反応しなければなりません。クライアントが複数回任意のオプションを指定しないでください。クライアントがこれを行う場合、それは一度だけのオプションを受け取ったかのようにしかし、サーバが行動しなければなりません。オプションは、クライアントによって指定される順序は重要ではありません。
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以外の各選択オプションは、対応するリターン・オプションが表示されます。 REMOTE選択オプションは、この点で異常であり、対応するリターンオプションはありません。それは、むしろ制限しよりも、返されるメールボックスのセットを拡張するためです。この仕様の将来の拡張を念頭に置いて並列性を維持し、対応するオプションのペアを定義する必要があります。
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.
この拡張は、機能文字列「LIST-EXTENDED」によって識別され、それに対するサポートは、LISTコマンドの特殊な形式を必要とする将来の拡張のための前提条件です。このような機能拡張は、この文書を参照する必要があり、ここで説明するように、コマンド・オプションを使用してその機能を追加しなければなりません。拡張さLISTコマンドのサポートが必要ですが、拡張されたLIST応答を使用していない拡張子が（下記参照）、「LIST-EXTENDED」機能の文字列を宣伝する必要はないことに注意してください。
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
この拡張は、エンドに拡張フィールドのシリーズ、（また、「拡張データ項目」という。）タグ付けされたデータの括弧リストを可能にする、LIST応答への拡張を定義します。拡張フィールドの最初の要素は、データのタイプを識別するタグです。このドキュメントのセクション9.5で説明したようにタグは、IANAに登録しなければなりません。そのような拡張されたセットの例があるかもしれません
tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text"))
テーブルクロス（（ "エッジ" "レース"）（ "色" "赤"）））（X-サンプル "テキスト"））
or
または
tablecloth ("edge" "lacy")) (X-Sample "text" "more text"))
テーブルクロス（ "エッジ" "レース"））（X-サンプル "テキスト"、 "複数のテキスト"））
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章では、正式な構文を参照してください。クライアントが拡張さLIST応答をサポートする能力を表明していない限り、サーバーは、拡張LISTコマンドを使用することにより、例えば、任意の拡張データアイテムを返してはなりません。サーバが直接対応するLISTコマンドでクライアントによって要請されていなかった、拡張フィールドのデータが返されることがあります。例えば、クライアントは、拡張LIST応答を利用する別のIMAP拡張機能を使用することにより、余分な拡張されたフィールドを有効にすることができます。クライアントは、それが認識されないすべての拡張フィールドを無視しなければなりません。
The LIST-EXTENDED capability also defines several new mailbox attributes.
LIST-EXTENDED機能もいくつかの新しいメールボックスの属性を定義します。
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:
「\存在しない」属性は、メールボックス名は、既存のメールボックスを参照していないことを示しています。この属性は、正規のLISTパターンに一致するが、以下に挙げる2つの条件の1も満たされない限り、返されてはならない存在しないメールボックス名として、単独では意味がないことに注意してください：
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は、」指定されており、メールボックス名は、LISTパターンと一致しないと選択基準と一致しない少なくとも一つの子孫のメールボックス名を持っています。
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).
実際には、これは「\存在しない」属性は、通常は「\リモート」、「\購読」の一つ以上で返されることを意味し、「\ 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コマンドを引き起こします。これは、多くの場合、実際のメールボックスのサブセットになります。このリストは存在しないメールボックスの名前を含むことも可能です。いずれの場合も、リストには、標準的なリストのパターンと一致するとに加入している正確にそれらのメールボックス名を含まなければなりません。このオプションは、LSUBコマンドを補足するものです。特に注目すべきはLSUBによって返されるものと比較して、このオプションによって返されるメールボックス属性です。後者では、返される属性は、メールボックス名に実際の属性の状態を反映していないかもしれない、と\ NOSELECT属性が第二特別な意味を持っている（それが加入し、自分自身、このメールボックスがないことを示しているが、それは子孫のメールボックスを持っていること）。ここで説明する加入選択オプションを使用すると、属性が正確かつ完全である、と特別な意味を持っていません。 「LSUB」と「LIST（サブスクライブ）は」このように、同じものではない、といくつかのサーバは、「LIST（サブスクライブ）」に対応するための重要な余分な作業を行う必要があります。このため、クライアントは、特に「LIST（サブスクライブ）」が提供する追加の情報を使用する場合に限り「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.
このオプションは、メールボックス名がサブスクライブされていることを示し、「\購読済み」新しいメールボックスの属性を定義します。 「\購読」属性をサポートしなければなりませんし、加入の選択オプションが指定されたときに正確に計算しなければなりません。
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.
REMOTE - [MBRef]で説明したようにLISTコマンドは、リモートメールボックスだけでなく、地元のものを表示するようになります。このオプションは、加入して選択オプション、RLSUBコマンドとともに、RLISTコマンドを置き換えるとすることを意図しています。
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オプションが指定されている場合、「\リモート」属性が正確に計算されなければなりません。
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.
REMOTE選択オプションは他のオプションとの相互作用を持っていません。その効果は地元のものに加えて、リモートメールボックスに、もしあれば、他のオプションを適用するには、サーバーに伝えることです。特に、それはRECURSIVEMATCH（下記参照）との相互作用を持っていません。 （RECURSIVEMATCH）の要求があるので（REMOTE RECURSIVEMATCH）の要求は、無効です。 （REMOTE 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：返される親メールボックスのためには、それはまだ標準的なLISTパターンに一致する必要があります。
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は、データ項目を拡張し返すとき、サブメールボックスは、標準的なLISTパターンと一致するか否かは問いません。第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オプションは、（または唯一のREMOTE付き）のみの選択オプションとして発生してはなりません。サーバーは、このような場合のBADタグ付けされた応答を返さなければなりません。
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コマンドの選択基準を満たすいかなるサブメールボックスは、存在しません/ 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).
サブスクライブ - 一致するすべてのメールボックス名のサブスクリプションの状態を返すために、LISTコマンドを引き起こします。 「\購読」属性をサポートしなければなりませんし、加入リターンオプションが指定されたときに正確に計算しなければなりません。さらに、すべてのメールボックスフラグが正確に（これは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.
このセクションでは、LIST応答がどのように多くの回答とそこに含まれる可能性のある情報の種類と同様に、返されるべきかどうかを決定するために、このドキュメントのサーバーの実装で使用できるいくつかの原則を概説します。
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つのLIST応答が正規のLISTパターンに一致する各メールボックス名のために返されるべきです。サーバーの実装は、クライアントが複数のLIST応答で返されたメールボックスの属性およびその他の情報を集めることができるようになりますと仮定してはいけません。
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.（サーバーが任意の時点で未承諾応答を返すことが許され、そして、そのような応答は、この規則によって支配されていないことに注意）LISTコマンドに応答してマッチングメールボックス名を含むための唯一の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.メールボックス名が選択基準を満たしていないが、それは、選択基準を満たす少なくとも一つの子孫のメールボックス名を持ち、それが正規LISTパターンと一致しません。
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. Attributes returned in the same LIST response must be treated additively. For example, the following response
同じLIST応答で返さ3.属性が付加的に処理されなければなりません。たとえば、次の応答
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S：* LIST（\購読\存在しない） "/" "フルーツ/ピーチ"
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.
クライアントがRECURSIVEMATCH選択オプションを指定している場合を除きCHILDINFO拡張データ項目が返されてはなりません。
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.
CHILDINFOはLIST応答してデータ項目を拡張し、それが返され、メールボックスが選択基準と一致する少なくとも一つの子孫メールボックスを持っていることを示しているさせた選択基準を記載しています。
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.
「\ NOSELECTは」ここにその本来の意味を保持するので、LSUBコマンドは、「\ NOSELECT」属性を使用して、この状態を示しますが、LIST（サブスクライブ）コマンドは、それを行うてはなりません。さらに、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選択オプションが指定されていない場合は、データ項目が許可されていない拡張ように、このようなサーバは、選択基準に一致する子孫のメールボックスがあることをクライアントに通知するために、「\存在しない\ 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.
返された選択基準は、クライアントが求められていないものから募集応答を区別するために、だけでなく、複数のパイプライン化さLISTによって引き起こさ勧誘応答を区別できるようにすることは、異なる条件を指定コマンド。
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.
少なくとも一つのマッチング子も返却されていない場合はサーバーのみ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は、データ項目と「\ HasChildren」属性拡張本CHILDINFOとの間の差を示します。
The following table summarizes interaction between the "\NonExistent" attribute and CHILDINFO (the first column indicates whether the parent mailbox exists):
次の表は、「\存在しない」属性と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の、もともとマイクGahrnsとレイモンド・チェンが提案した子メールボックスの拡張を実装し返します。このセクションの情報のほとんどは、[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]クライアント。むしろ最初にユーザーにメールボックス全体の階層を提示するよりも、ユーザーのメールボックス階層の崩壊概要リスト（メールボックスの数が多い場合は特に）に示すことが好ましい場合が多いです。必要に応じて、ユーザは、折りたたまれたアウトライン階層を展開することができます。特定のメールボックスの下の子のメールボックスが存在することを示すために（例えば「「」+」のように）崩壊した階層内の視覚的な手がかりを含めるのが一般的です。視覚的な手がかりをクリックすると、階層リストは、子メールボックスを表示するように拡張されます。子どもたちは、クライアントが効率的に各メールボックス名のLIST「」*またはLIST「」％を発行せず、特定のメールボックスが子を持つかどうかを判断するためのオプションは、メカニズムを提供し返します。 \ HasChildrenと\ HasNoChildren：CHILDRENオプションはLIST応答の中に返されなければならない2つの新しい属性を定義して返します。これらの属性は、任意のLISTコマンドに応答して返されることがありますが、子どもたちはオプションは、クライアントが特にこの情報を望んでいることを示すために提供されて戻ります。子どもたちはオプションが存在している返す場合、サーバーは、その計算が高価であっても、これらの属性を返さなければなりません。
\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属性でマークされている場合、クライアントは、状況に対処するために準備しておく必要がありますが、ない子メールボックスはで表示されませんLISTコマンドに応答。これは、サーバーがそれらを一覧表示することができます前に、メールボックスが別のクライアントによって（アクセス制御を使用して）利用者に削除またはアクセス不能に作られている子どもたちに、例えば、起こるかもしれません。
\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と同じLIST応答で\ 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
C：A01 LIST "" "*" S：* LIST（\マーク\ NoInferiors） "/" "受信箱" S：* LIST（） "/" "フルーツ" S：* LIST（） "/"「フルーツ/アップル"S * LIST（） "/" "果物/バナナ" S * LIST（） "/" "豆腐" S：* LIST（） "/" "植物" S * LIST（） "/"" 野菜/ブロッコリー」S：* LIST（） "/" "野菜/コーン" S：A01 OK済
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「」「*」>と同等に似ていますが、ありません。 「フルーツ/ピーチ」と呼ばれるメールボックスが加入しているが、実際には存在しないことに注意してください（おそらくそれはまだ加入している間に削除されました）。 「フルーツ」メールボックスがに加入したが、それは2購読人の子供を持っていません。 「野菜」のメールボックスには加入して2人の子供を持っていています。そのうちの一つは、同様に加入しています。
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
C：A02 LIST（サブスクライブ） "" "*" S：* LIST（\マーク\ NoInferiors \購読） "/" "受信箱" S：* LIST（\購読） "/" "フルーツ/バナナ" S：* LIST （\購読\存在しない） "/" "フルーツ/ピーチ" S：* LIST（\購読） "/" "野菜" S：* LIST（\購読） "/" "野菜/ブロッコリー" S：A02 OK済
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：次の例では、子どものオプションを使用することを示しています。クライアントは、階層の第二のレベルを一覧表示することなく、今サブメールボックス（子どもを）持っているトップレベルのメールボックスのどのとそうでないかを知っています。サーバーは、受信トレイのために\ HasNoChildren属性を返すようにするために、\ NoInferiorsが既にあることを意味し、より強力な意味を持つ属性ので、それは、必要はありませんので注意してください。
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
C：A03 LIST（） "" "％" RETURN（CHILDREN）S：* LIST（\マーク\ NoInferiors） "/" "受信箱" S：* LIST（\ HasChildren） "/" "フルーツ" S：* LIST（ \ HasNoChildren） "/" "豆腐" S：* LIST（\ HasChildren） "/" "野菜" S：A03 OK済
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
C：A04 LIST（REMOTE） "" "％" RETURN（CHILDREN）S：* LIST（\マーク\ NoInferiors） "/" "受信箱" S：* LIST（\ HasChildren） "/" "フルーツ" S：* LIST （\ HasNoChildren） "/" "豆腐" S：* LIST（\ HasChildren） "/" "野菜" S：* LIST（\リモート） "/" "パン" S：* LIST（\ HasChildrenリモート\）「/ 「 "肉" S：A04 OK済
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
C：A05 LIST（REMOTE加入） "" "*" S：* LIST（\ \ NoInferiors \購読マーク） "/" "受信箱" S：* LIST（\購読） "/" "フルーツ/バナナ" S：* LIST（\購読\存在しない） "/" "フルーツ/ピーチ" S：* LIST（\購読） "/" "野菜" S：* LIST（\購読） "/" "野菜/ブロッコリー" S：* LIST（ \リモート\購読） "/" "パン" S：A05 OK済
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
C：A06 LIST（REMOTE） "" "*" RETURN（加入）S：* LIST（\ \ NoInferiors \購読マーク） "/" "受信箱" S：* LIST（） "/" "フルーツ" S：* LIST （） "/" "フルーツ/アップル" S：* LIST（\購読） "/" "フルーツ/バナナ" S：* LIST（） "/" "豆腐" S：* LIST（\購読） "/" "野菜」S：* LIST（\購読） "/" "野菜/ブロッコリー" S：* LIST（） "/" "野菜/コーン" S：* LIST（\リモート\購読） "/" "パン" S： * LIST（\リモート） "/" "肉" S：A06 OK済
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
C：BBBのLIST ""（ "INBOX" "下書き" "送信済み/％"）S：* LIST（） "/" "INBOX" S：* LIST（\ NoInferiors） "/" "下書き" S：* LIST（ ） "/" "/ March2004送信" S：* LIST（\マーク） "/" "送信済み/ December2003" S：* LIST（） "/" "送信済み/ August2004" S：BBB OKを完了
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
C：C01のLIST "" "*" S：* LIST（\マーク\ NoInferiors） "/" "受信箱" S：* LIST（） "/" "フー" S：* LIST（） "/"「フー/バー「S：* LIST（） "/" "はFoo /バズ" S：* LIST（） "/" "武" S：C01 OKが行わ
If the client asks RETURN (CHILDREN), it will get this:
クライアントは、RETURN（CHILDREN）を要求する場合は、これを取得します。
C: CA3 LIST "" "%" RETURN (CHILDREN) S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\HasChildren) "/" "Foo" S: * LIST (\HasNoChildren) "/" "Moo" S: CA3 OK done
C：CA3のLIST "" "％" RETURN（CHILDREN）S：* LIST（\マーク\ NoInferiors） "/" "受信箱" S：* LIST（\ HasChildren） "/" "フー" S：* LIST（\ HasNoChildren ） "/" "武" S：CA3 OK済
A) Let's also assume that the mailbox "Foo/Baz" is the only subscribed mailbox. Then we get this result:
A）のもメールボックス「はFoo /バズは」唯一の購読メールボックスであると仮定しよう。その後、我々はこの結果を得ます：
C: C02 LIST (SUBSCRIBED) "" "*" S: * LIST (\Subscribed) "/" "Foo/Baz" S: C02 OK done
C：C02 LIST（サブスクライブ） "" "*" S：* LIST（\購読） "/" "はFoo /バズ" S：C02 OKを完了
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（サブスクライブ）「」「％」>場合、サーバは（メールボックス「武」として、「フー」、および「受信トレイ」を購読していないされている）は、メールボックスを返しません。ただし、クライアントはこれを発行した場合：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) S: C04 OK done
C：C04リスト（加入RECURSIVEMATCH） "" "％" S * LIST（） "/" "foo" という（ "CHILDINFO"（ "購読"））S：C04 OKが完了
(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）は、最後のコマンドは、これを返します：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) S: C04 OK done
C：C04 LIST（加入RECURSIVEMATCH） "" "％" S：* LIST（\購読） "/" "フー"（ "CHILDINFO"（ "加入"））S：C04 OKを完了
or even this:
あるいは、この：
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) S: C04 OK done
C：C04のLIST（加入RECURSIVEMATCH） "" "％" S：* LIST（\購読\ HasChildren） "/" "フー"（ "CHILDINFO"（ "加入"））S：C04 OKを完了
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:
我々は、メールボックス「foo」が、元の階層の一部ではなく、加入していないことを代わりに仮定した場合A2）、最後のコマンドは、この結果が得られます。
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) S: C04 OK done
C：C04のLIST（加入RECURSIVEMATCH） "" "％" S：* LIST（\存在しない） "/" "フー"（ "CHILDINFO"（ "加入"））S：C04 OKを完了
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）それでは、何のメールボックスが加入していないと仮定してみましょう。何のサブスクライブ子が存在しないとしてこの場合は、コマンド<LIST（加入RECURSIVEMATCH）「」「％」は>（「foo」が子供を持っているにもかかわらず）、何の応答を返しません。
C) And finally, suppose that only the mailboxes "Foo" and "Moo" are subscribed. In that case, we see this result:
C）そして最後には、メールボックスのみが「foo」と「武」が加入していると仮定します。その場合には、我々はこの結果を参照してください。
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN) S: * LIST (\HasChildren \Subscribed) "/" "Foo" S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" S: C04 OK done
C：C04 LIST（加入RECURSIVEMATCH） "" "％" RETURN（CHILDREN）S：* LIST（\ HasChildren \購読） "/" "フー" S：* LIST（\ HasNoChildren \購読） "/" "武" S ：C04 OKが行わ
(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は、データ項目が子供のメールボックスが正規LISTパターンに一致するか否かが返される拡張ことを実証しています。
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
C：D01 LIST "" "*" S：* LIST（\マーク\ NoInferiors） "/" "受信箱" 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 /マンバ" S：* LIST（ ） "/" "qux2 / BAR2" S：済D01のOK
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
C：D02 LIST（サブスクライブ） "" "*" S：* LIST（\購読） "/" "foo2は/ BAR1" S：* LIST（\購読） "/" "foo2は/ BAR2" S：* LIST（\購読） "/" "baz2 / BAR2" S：* LIST（\購読） "/" "baz2 / bar22" S：* LIST（\購読） "/" "baz2 / bar222" S：* LIST（\購読） "/" "eps2" S：* LIST（\購読） "/" "eps2 /マンバ" S：* LIST（\購読） "/" "qux2 / BAR2" S：D02のOKが行わ
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
C：D03 LIST（RECURSIVEMATCH加入） "" "* 2" S：* LIST（） "/" "foo2は"（ "CHILDINFO"（ "加入"））S：* LIST（\購読） "/"「foo2は/ BAR2" S：* LIST（\購読） "/" "baz2 / BAR2" S：* LIST（\購読） "/" "baz2 / bar22" S：* LIST（\購読） "/" "baz2 / bar222" S：* LIST（\購読） "/" "eps2"（ "CHILDINFO"（ "加入"））S：* LIST（\購読） "/" "qux2 / BAR2" S：D03のOKが行わ
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"))
S：* LIST（） "/" "baz2"（ "CHILDINFO"（ "加入"））S：* LIST（\存在しない） "/" "qux2"（ "CHILDINFO"（ "加入"））
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は」2人の加入子どもの一方のみがために、パターンに一致するためにもかかわらず、「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
C：D03 LIST（RECURSIVEMATCH加入） "" "*" S：* LIST（） "/" "foo2は"（ "CHILDINFO"（ "加入"））S：* LIST（\購読） "/"「foo2は/ BAR1 "S：* LIST（\購読） "/" "foo2は/ BAR2" S：* LIST（） "/" "baz2"（" CHILDINFO」（ "加入"））S：* LIST（\購読） "/" "baz2 / BAR2" S：* LIST（\購読） "/" "baz2 / bar22" S：* LIST（\購読） "/" "baz2 / bar222" S：* LIST（\購読） "/"「eps2 "（" CHILDINFO」（ "加入"））S：* LIST（\購読） "/" "eps2 /マンバ" S：* LIST（\購読） "/" "qux2 / BAR2" S：D03のOKが行わ
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」のLIST応答はまだこの情報は冗長であり、クライアントは自身でそれを判断できるにもかかわらず、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
C：A3 LIST（加入RECURSIVEMATCH） "" FOOのRETURN（CHILDREN）S：* LIST（\ HasNoChildren） "/" fooの（ "CHILDINFO"（ "加入"））S：A3 OKを完了
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：A1 LIST（REMOTE） "" * S：* LIST（） "/" 音楽/ロックS：* LIST（\リモート） "/" も/ジャズ・S：完了A1 OK
C: a2 LIST () "" % S: * LIST (\NonExistent \HasChildren) "/" music S: a2 OK done
C：A2 LIST（） "" ％S：* LIST（\存在しない\ HasChildren） "/" 音楽S：A2 OKを完了
C: a3 LIST (REMOTE) "" % S: * LIST (\NonExistent \HasChildren) "/" music S: * LIST (\NonExistent \HasChildren) "/" also S: a3 OK done
C：A3 LIST（REMOTE） "" ％S：* LIST（\存在しない\ HasChildren） "/" 音楽S：* LIST（\存在しない\ HasChildren） "/" もS：A3 OKが行わ
C: a3.1 LIST "" (% music/rock) S: * LIST () "/" music/rock S: a3.1 OK done
C：A3.1のLIST ""（％音楽/ロック）S：* LIST（） "/" 音楽/ロックS：済A3.1のOK
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.
「音楽/ロック」は「音楽」でのみメールボックスがあるので、また「音楽」を返すようにサーバーは必要ありません。しかし、クライアントは両方のケースを処理する必要があります。
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]から取得されます。具体的には、LIST応答のペイロードを定義し、以下「メールボックスリスト」のバージョンなお、IMAP仕様で定義されたバージョンを更新します。これは、[IMAP4]で定義される「メールボックスデータ」によって指し示されます。
"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.
childinfo拡張項目は=「CHILDINFO」SP「（」リスト・セレクト・ベースオプト引用*（SPリスト・セレクト・ベースオプト引用）「）」。拡張データ項目（MBOXリスト拡張項目）。ときRECURSIVEMATCH返さ。選択オプションが指定されています。 ;注1：CHILDINFOタグを返すことができます。あたりとして引用符を、周囲なし。 MBOX-リスト拡張項目タグの生産。 ;注2：選択オプションが常に返されます。での仕様とは異なり、引用されました。拡張さLISTコマンド。
child-mbox-flag = "\HasChildren" / "\HasNoChildren" ; attributes for CHILDREN return option, at most one ; possible per LIST response
子供のmbox-フラグ= "\ HasChildren" / "\ HasNoChildren"。子供のための属性はオプションで、最大1つを返します。 LIST応答あたりの可能性
eitem-standard-tag = atom ; a tag for extended list data defined in a Standard ; Track or Experimental RFC.
eitem標準タグ=原子;規格で定義された拡張リストデータ用のタグ。トラックや実験的RFC。
eitem-vendor-tag = vendor-token "-" atom ; a vendor-specific tag for extended list data
eitemベンダータグ=ベンダートークン「 - 」原子;拡張されたリストデータのベンダー固有のタグ
list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat [SP list-return-opts]
リスト= "LIST" [SPリスト選択-optsの] SPメールボックスのSPのmbox-または-パット[SPリスト・リターン-optsの]
list-return-opts = "RETURN" SP "(" [return-option *(SP return-option)] ")" ; list return options, e.g., CHILDREN
一覧リターン-optsの= "RETURN" SP "（" [リターン・オプション*（SP戻る-オプション）] "）";リストのリターンオプション、例えば、CHILDREN
list-select-base-opt = "SUBSCRIBED" / option-extension ; options that can be used by themselves
リスト選択ベース-OPT = "加入" /オプションの拡張;単独で使用可能なオプション
list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
= DQUOTEリスト・セレクト・ベース・オプト引用されたリストを選択-ベース-OPT DQUOTE
list-select-independent-opt = "REMOTE" / option-extension ; options that do not syntactically interact with ; other options
リスト選択に依存しない-OPT = "REMOTE" /オプションの拡張;構文的に相互作用しないオプション。別のオプション
list-select-mod-opt = "RECURSIVEMATCH" / option-extension ; options that require a list-select-base-opt ; to also be present
リスト選択-MOD-OPT = "RECURSIVEMATCH" /オプションの拡張;リスト選択ベース-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.
リスト選択-OPT =リスト・セレクト・ベース-OPT /リスト選択に依存しない-OPT /リスト選択-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)
リスト選択-OPTS = "（" [（*（リスト選択-OPT SP）リスト・セレクト・ベース-OPT×（SPリスト選択-OPT））/（リスト選択に依存し-OPT×（SPリスト-Selectに依存しない-OPT））] "）";オプションの任意の数は、任意の順序であってもよいです。 ;リスト選択-MOD-OPTが表示された場合は、その後、リスト選択ベース-optがまた現れなければなりません。 ;これは、これらのことができます：; （）; （REMOTE）。 （加入）。 （加入REMOTE）。 （加入RECURSIVEMATCH）。 （加入REMOTE RECURSIVEMATCH）。しかし、これらを許可していません; （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]
メールボックスリスト= "（" [MBX-リストフラグ "）" SP（DQUOTE QUOTED-CHAR DQUOTE / NIL）SPメールボックス[SPのMBOXリスト拡張]。この情報はABNFで指さリストです。 [IMAP4]で定義されている項目「メールボックス・データ」、
mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")"
MBOXリスト拡張=「（」[MBOXリスト拡張項目*（SP MBOXリスト拡張項目）]「）」
mbox-list-extended-item = mbox-list-extended-item-tag SP tagged-ext-val
MBOX-リスト拡張アイテム= MBOXリスト拡張項目タグSPタグ化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.
MBOXリスト拡張項目タグ=のAString。内容は「eitemベンダータグ」のいずれかに従わなければなりません。または「eitem標準タグ」ABNF制作。 ;タグ登録テンプレートは、この中に記載されています。 9.5節で文書。
mbx-list-oflag =/ child-mbox-flag / "\Subscribed" / "\Remote"
MBX-リストはoflag = /子供のmbox-フラグ/ "\購読済み" / "\リモート"
mbx-list-sflag =/ "\NonExistent"
MBX-リストSFLAG = / "\存在しません"
mbox-or-pat = list-mailbox / patterns
MBOX-または-パット=リストのメールボックス/パターン
option-extension = (option-standard-tag / option-vendor-tag) [SP option-value]
オプション拡張=（オプション標準タグ/オプションベンダータグ）[SPオプション値]
option-standard-tag = atom ; an option defined in a Standards Track or ; Experimental RFC
オプション標準タグ=原子;標準化過程かで定義されたオプション。実験的RFC
option-val-comp = astring / option-val-comp *(SP option-val-comp) / "(" option-val-comp ")"
=のAString /オプション・ヴァル・コンプ*オプション-VAL-COMP（SPオプション-VAL-COMP）/ "（" オプション-VAL-COMP "）"
option-value = "(" option-val-comp ")"
オプション値= "（" オプション-VAL-COMP "）"
option-vendor-tag = vendor-token "-" atom ; a vendor-specific option, non-standard
オプション・ベンダータグ=ベンダートークン「 - 」原子;ベンダー固有のオプション、非標準
patterns = "(" list-mailbox *(SP list-mailbox) ")"
パターン=「（」リストのメールボックス*（SPリスト・ボックス）「）」
return-option = "SUBSCRIBED" / "CHILDREN" / option-extension
リターンオプション=「加入」/「CHILDREN」/オプションの拡張
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.
タグ付けされた-EXT-COMP =のAString /タグ付き-EXT-コンプ*（SPタグ化EXT-COMP）/ "（" タグ-EXT-COMP "）"。この一般的に続く拡張機能。構文はnstringの代わりに使用する必要があります。 AStringとき文脈における適切な。拡張子の。 ;設定されたメッセージまたは「数」ことに留意されたいです。常に「原子」として表すことができます。 ; URLは次のように表現されなければなりません。 「引用符で囲まれた」文字列。
tagged-ext-simple = sequence-set / number
タグ付けされた-EXT-シンプル=シーケンスセット/数
tagged-ext-val = tagged-ext-simple / "(" [tagged-ext-comp] ")"
タグ付けされた-EXT-VAL =タグ付けさ-EXT-簡単/ "（" [タグ付けさ-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.
この仕様で定義されたLISTコマンド選択オプションタイプは、メールボックスのプロパティの簡単なテストを伴います。しかし、LIST-EXTENDEDへの将来の拡張には、より洗練されたテストを行う選択オプションを定義することもできます。一致するテキストを必要とする試験の場合には、コンパレータ[I18N]拡張の存在下で、活性コンパレータが比較を行うために使用されなければなりません。そのようなLIST-EXTENDED拡張は、その明細書のコンパレータ[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コマンドのLIST、LSUB、RLIST、およびRLSUBの仕様構文の変更点について説明し、修正LISTコマンドは、これらのコマンドと同じセキュリティ上の考慮事項があります。彼らは、[MBRef] [IMAP4]で説明しています。
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.
子メールボックスの拡張はクライアントに特定のメールボックスが子を持つかどうかを決定するためのより効率的な手段を提供します。メールボックスが子供を持っていますが、現在は認証されたユーザがそれらのいずれかへのアクセス権を持っていない場合、サーバーは\ 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は、LIST-EXTENDEDオプションとLIST-EXTENDED応答データ用の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.
LIST-EXTENDEDオプションの登録は、第9.3節で、テンプレートに記入し、iana@iana.orgに電子メール経由で送信することで行われます。 LIST-EXTENDED拡張データ項目の登録は、セクション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-」で始まるLIST-EXTENDEDオプション/拡張データ項目名は、ベンダー固有のオプション/拡張データ項目のために予約されています。すべてのオプションは、彼らはベンダ固有またはグローバルであるかどうか、IANAに登録する必要があります。 LIST-EXTENDED拡張データ項目が特定のリスト拡張オプションを要求した結果として返された場合、オプションの名前は、リストEXTENDED拡張データ項目の名称として使用されるべきです。
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.
標準LIST-EXTENDEDオプション/拡張データ項目名は大文字小文字を区別しません。ベンダープレフィックスは、ベンダー固有のLIST-EXTENDEDオプション/拡張データ項目名から省略されている場合、残りは大文字と小文字を区別しません。それは非ASCII文字が含まれている可能性があるため、ベンダープレフィックス自体は、大文字と小文字を区別しません。登録手続きは、それを必要としませんが、LIST-EXTENDEDオプション/拡張データ項目の作成者は、コミュニティの見直しを求め、それが実現可能である時はいつでもコメントすることが奨励されています。著者は、インターネットドラフトとしての提案されたメカニズムの仕様を掲載することにより、コミュニティの見直しを求めることができます。適切な場合に普及することを意図LIST-拡張オプション/拡張データ項目は、通常の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.
登録さLIST-EXTENDEDオプション/拡張応答データのコメントは、第一および/またはIMAPEXT WGメーリングリストへのメカニズムの「所有者」に送信する必要があります。コメントの提出者は、所有者に連絡するために合理的な試みの後、登録自体に自分のコメントを添付するIANAを要求することができます。 IANAは、このを承認する場合は、コメントが登録LIST-EXTENDEDオプション/拡張応答データそのものと一緒にアクセスできるようになります。
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.
LIST-EXTENDED登録は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.
LIST-EXTENDED登録の所有者は、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オプション/拡張データ項目の責任を再割り当てすることができます。この最も一般的な場合は、登録の作者が死亡したメカニズムに行われる変更を可能にすることであろう、接触の外に移動、またはコミュニティへの重要な変更を行うことができないそうしました。
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.
LIST-EXTENDED登録が削除されない場合があります。もはや使用するのに適したと考えられているメカニズムは、彼らの「意図する使用」フィールドへの変更によってOBSOLETEと宣言することができます。このようなLIST-EXTENDEDオプション/拡張データ項目は明らかに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標準化過程の上にあるすべてのLIST-拡張オプション/拡張データ項目の所有者であると考えられています。
To: iana@iana.org Subject: Registration of LIST-EXTENDED option X
To：iana@iana.org件名：LIST-EXTENDEDオプションXの登録
LIST-EXTENDED option name:
LIST-EXTENDEDオプション名：
LIST-EXTENDED option type: (One of SELECTION or RETURN)
LIST-EXTENDEDオプションタイプ：（選択またはRETURNの一つ）
Implied return options(s), if the option type is SELECTION: (zero or more)
暗黙のリターンオプション（複数可）、オプションタイプは、選択された場合：（ゼロ個以上）
LIST-EXTENDED option description:
LIST-EXTENDEDオプションの説明：
Published specification (optional, recommended):
公開された仕様（オプション、推奨）：
Security considerations:
セキュリティの考慮事項：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図している用法：（COMMONの一つ、限られた使用、またはOBSOLETE）
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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:
LIST-EXTENDEDオプションのレジストリは、次のエントリが取り込まれました：
1. To: iana@iana.org Subject: Registration of LIST-EXTENDED option SUBSCRIBED
1.宛先：iana@iana.org件名：LIST-EXTENDEDオプションの登録加入
LIST-EXTENDED option name: SUBSCRIBED
LIST-EXTENDEDオプション名：サブスクライブ
LIST-EXTENDED option type: SELECTION
LIST-EXTENDEDオプションタイプ：SELECTION
Implied return options(s): SUBSCRIBED
暗黙のリターンオプション（S）：サブスクライブ
LIST-EXTENDED option description: Causes the LIST command to list subscribed mailboxes, rather than the actual mailboxes.
LIST-EXTENDEDオプションの説明：サブスクライブされたメールボックスではなく、実際のメールボックスを一覧表示するLISTコマンドを引き起こします。
Published specification: RFC 5258, Section 3.
公開された仕様：RFC 5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティの考慮事項：RFC 5258、セクション8。
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
2. To: iana@iana.org Subject: Registration of LIST-EXTENDED option REMOTE
2.宛先：iana@iana.org件名：REMOTE LIST-EXTENDEDオプションの登録
LIST-EXTENDED option name: REMOTE
LIST-EXTENDEDオプション名：REMOTE
LIST-EXTENDED option type: SELECTION
LIST-EXTENDEDオプションタイプ：SELECTION
Implied return options(s): (none)
暗黙のリターンオプション（S）：（なし）
LIST-EXTENDED option description: Causes the LIST command to return remote mailboxes as well as local ones, as described in RFC 2193.
LIST-EXTENDEDオプションの説明：RFC 2193で説明したように、リモートメールボックスだけでなく、地元のものを返すために、LISTコマンドを引き起こします。
Published specification: RFC 5258, Section 3.
公開された仕様：RFC 5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティの考慮事項：RFC 5258、セクション8。
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
3. To: iana@iana.org Subject: Registration of LIST-EXTENDED option SUBSCRIBED
3.宛先：iana@iana.org件名：LIST-EXTENDEDオプションの登録加入
LIST-EXTENDED option name: SUBSCRIBED
LIST-EXTENDEDオプション名：サブスクライブ
LIST-EXTENDED option type: RETURN
LIST-EXTENDEDオプションタイプ：RETURN
LIST-EXTENDED option description: Causes the LIST command to return subscription state.
LIST-EXTENDEDオプションの説明：サブスクリプションの状態を返すために、LISTコマンドを引き起こします。
Published specification: RFC 5258, Section 3.
公開された仕様：RFC 5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティの考慮事項：RFC 5258、セクション8。
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
4. To: iana@iana.org Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH
4.宛先：iana@iana.org件名：LIST-EXTENDEDオプションの登録RECURSIVEMATCH
LIST-EXTENDED option name: RECURSIVEMATCH
LIST-EXTENDEDオプション名：RECURSIVEMATCH
LIST-EXTENDED option type: SELECTION
LIST-EXTENDEDオプションタイプ：SELECTION
Implied return options(s): (none)
暗黙のリターンオプション（S）：（なし）
LIST-EXTENDED option description: Requests that CHILDINFO extended data item (childinfo-extended-item) is to be returned.
LIST-EXTENDEDオプションの説明：CHILDINFOは、データ項目（childinfo拡張項目を）延長要求が返されます。
Published specification: RFC 5258, Section 3.
公開された仕様：RFC 5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティの考慮事項：RFC 5258、セクション8。
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
5. To: iana@iana.org Subject: Registration of LIST-EXTENDED option CHILDREN
5.宛先：iana@iana.org件名：LIST-EXTENDEDオプションCHILDRENの登録
LIST-EXTENDED option name: CHILDREN
LIST-EXTENDEDオプション名：CHILDREN
LIST-EXTENDED option type: RETURN
LIST-EXTENDEDオプションタイプ：RETURN
LIST-EXTENDED option description: Requests mailbox child information.
LIST-EXTENDEDオプションの説明：メールボックスの子情報を要求します。
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
意図している用法：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
To: iana@iana.org Subject: Registration of X LIST-EXTENDED extended data item
To：iana@iana.org件名：XのLIST-EXTENDED拡張データ項目の登録
LIST-EXTENDED extended data item tag:
LIST-EXTENDED拡張データ項目タグ：
LIST-EXTENDED extended data item description:
LIST-EXTENDED拡張データ項目の説明：
Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any):
どのLIST-EXTENDEDオプション（S）（およびその種類）が（もしあれば）この拡張データ項目が戻されます。
Published specification (optional, recommended):
公開された仕様（オプション、推奨）：
Security considerations:
セキュリティの考慮事項：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図している用法：（COMMONの一つ、限られた使用、またはOBSOLETE）
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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:
LIST-EXTENDED拡張データ項目のレジストリには、次のエントリが取り込まれました：
1. To: iana@iana.org Subject: Registration of CHILDINFO LIST-EXTENDED extended data item
1.宛先：iana@iana.org件名：CHILDINFO LIST-EXTENDED拡張データ項目の登録
LIST-EXTENDED extended data item tag: CHILDINFO
LIST-EXTENDED拡張データ項目タグ：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.
LIST-EXTENDED拡張データ項目の説明：CHILDINFO拡張データアイテム、それが返され、メールボックスが選択基準に一致する1つ以上の子メールボックスを持っていることを示していることが原因となった選択基準を説明しています。
Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any): RECURSIVEMATCH selection option
どのLIST-EXTENDEDオプション（S）（およびその種類）が（もしあれば）この拡張データ項目が戻されます：RECURSIVEMATCH選択オプション
Published specification: RFC 5258, Section 3.5.
公開された仕様：RFC 5258、セクション3.5。
Security considerations: RFC 5258, Section 8.
セキュリティの考慮事項：RFC 5258、セクション8。
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
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.
マイクGahrnsとマイクロソフト社のレイモンド・チェンは、もともと子メールボックスの拡張を考案し、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メーリングリストでの議論の結果であり、これらのグループの総意を反映するものです。特に、マーク・クリスピン、フィリップ・ギュンター、サイラスDaboo、ティモ・シレーヌン、ケンマーチソン、ロブSiemborskiは、スティーブ・ホール、ARNT Gulbrandsenの、ラリー・グリーンフィールド、デイブCridland、そしてピート・マクリーンは、この文書にそれらの議論や作られた提案に積極的に参加しました。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]クロッカー、D.、エド。そして、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]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[I18N]ニューマン、C.、Gulbrandsenの、A.、およびA.メルニコフ、 "インターネットメッセージアクセスプロトコル国際化"、RFC 5255、2008年6月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP4]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[Kwds]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月。
[MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September 1997.
[MBRef] Gahrns、M.、 "IMAP4メールボックスの紹介"、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.チェン、 "インターネットメッセージアクションプロトコル（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スカイラインドライブホーソーン、NY 10532米国
Phone: +1 914 784 7941 EMail: leiba@watson.ibm.com
電話：+1 914 784 7941 Eメール：leiba@watson.ibm.com
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/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。