RFC5258 日本語訳
5258 Internet Message Access Protocol version 4 - LIST CommandExtensions. B. Leiba, A. Melnikov. June 2008. (Format: TXT=65074 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
Leibaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 5258 IBM T.J.ワトソン研究所は以下を時代遅れにします。 3348のA.メリニコフアップデート: 2193年のIsode株式会社カテゴリ: 標準化過程2008年6月
Internet Message Access Protocol version 4 - LIST Command Extensions
インターネットMessage Accessプロトコルバージョン4--LIST Command Extensions
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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。 私たちが加えたように、各拡大がLISTとLSUBの両方に機能を加えなければならないので、私たちが持っている専門化しているリストを必要としたMailbox Referralsなどの拡張子はリストコマンドの数を広くしなければなりませんでした、そして、それらが定義されるので、これらのコマンドは広げることができません。 一緒に働くために拡大を必要としたなら、私たちは異なったオプションを混ぜる1セットのコマンドを加えなければなりませんでした、それぞれの新しい拡大に応じてセットが大きくなって。 このドキュメントはこれらの追加が互いにコンパチブルオプションでLISTコマンドに大丈夫にさせるベースLISTコマンドに拡大について説明します、専門化しているリストコマンドの急激な増加を避けて。
Leiba & Melnikov Standards Track [Page 1] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[1ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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
1. 序論と概要. . . . . . . . . . . . . . . . . . 3 2。 コンベンションは本書では.4 3を使用しました。 拡張リストコマンド. . . . . . . . . . . . . . . . . . . . 4 3.1。 選択オプション. . . . . . . . . . . . 7 3.2のリストに頭文字をつけてください。 リターンオプション. . . . . . . . . . . . . . 8 3.3のリストに頭文字をつけてください。 戻るための綱領は応答. . . . . 9 3.4を記載します。 リストで拡張しているクライアント. . . . . 9 3.5に関する追加要件。 CHILDINFOはデータ項目. . . . . . . . . . . . . . . 10 4を広げました。 子供はオプション. . . . . . . . . . . . . . . . . . 11 5を返します。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6。 正式な構文. . . . . . . . . . . . . . . . . . . . . . . . 19 7。 国際化問題. . . . . . . . . . . . . 22 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 23 9.1。 IANA. . . . . . . . . . . . . . . . . . . 23 9.2のためのガイドライン。 登録手順と変化コントロール. . . . . . . . 23 9.3。 登録のテンプレートの繰返し要素の並びで拡張しているオプション. . . . . 25 9.4。 リストで拡張しているオプション登録証明書. . . . . . . . 25 9.5に頭文字をつけてください。 登録のテンプレートの繰返し要素の並びで拡張している拡張データ項目. . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.6。 リストで拡張している拡張データ項目登録証明書. . 28 10に頭文字をつけてください。 承認. . . . . . . . . . . . . . . . . . . . . . . 29 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 29 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 30
Leiba & Melnikov Standards Track [Page 2] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[2ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
1. Introduction and Overview
1. 序論と概要
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つが本当であるなら、新しい構文は使用されています:
1. if the first word after the command name begins with a
parenthesis ("LIST selection options")
1. 1番目であるなら、コマンド名の後の単語は挿入句で始まります。(「LIST選択オプション」)
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リターンオプション」)
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を非難する意図を発表しています。 また、私たちは、Child Mailbox Extension[CMbox]で説明されるような拡張メールボックス情報を要求するためにメカニズムを定義しています。 ベースLSUBコマンドはこの拡大で推奨しなくはありません。 むしろ、この拡大は、より多くのオプション、それをサポートするそれらのサーバ実装で購読情報を得る方法を加えます。 LSUBコマンドで提供するように単に申し込まれたメールボックスのリストを必要とするクライアント、SHOULDはそのコマンドを使用し続けています。
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拡張子を定義します。 LIST-EXTENDED拡張子は以下の変更を行います:(変更はさらに詳細にセクション3とセクション4にIMAP4プロトコルに説明されます)。
a. defines new syntax for LIST command options.
a. LISTコマンドオプションのための新しい構文を定義します。
b. extends LIST to allow for multiple mailbox patterns.
b. 複数のメールボックスパターンを考慮するためにLISTを広げています。
c. adds LIST command selection options: SUBSCRIBED, REMOTE, and
RECURSIVEMATCH.
c. LISTコマンド選択オプションを加えます: 申し込まれて、リモートである、そして、RECURSIVEMATCH。
d. adds LIST command return options: SUBSCRIBED and CHILDREN.
d. LISTコマンドリターンオプションを加えます: 申し込まれました。そして、子供。
e. adds new mailbox attributes: "\NonExistent", "\Subscribed",
"\Remote", "\HasChildren", and "\HasNoChildren".
e. 新しいメールボックス属性を加えます: 「「\実在しません」であっ」て、\が申し込まれた、」、」、\リモートである、」、」、\HasChildren、」 」 \HasNoChildren、」
Leiba & Melnikov Standards Track [Page 3] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[3ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
f. adds CHILDINFO extended data item.
f. CHILDINFOがデータ項目を広げたと言い足します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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"、「必須NOT」“SHOULD"、「」 「5月」はRFC2119[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.
「正準なLISTパターン」という用語はサーバによって参照とメールボックス名前引数(.8セクション6.3[IMAP4])から内部的に構成された正準なパターンを参照します。 [IMAP4]LISTコマンドは正準なLISTパターンに合っているメールボックスだけを返します。
Other terms are introduced where they are referenced for the first time.
他の用語はそれらが初めて参照をつけられるところで紹介されます。
3. Extended LIST Command
3. 拡張リストコマンド
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つのメールボックスパターンを合わせるなら、メールボックス名はメールボックスパターンのリストに合っています。 メールボックス名がリストからの複数のメールボックスパターンに合っているなら、サーバSHOULDはただ一つの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]に従って)で与えられた名前の階層構造デリミタと根の名を返すという特別な要求としてのメールボックス名前引数。」 しかしながら、どんな拡張LISTコマンド(セクション1で指定された、3つの方法、またはそれのどんな組み合わせのどれかでも、広がっている)もそのような特別な要求として空のメールボックス名を扱ってはいけません、そして、本書では説明されたどんな定期的な処理も適用されます。 特に、拡張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コマンド構文は2つの追加方法で広げられます: そして、コマンド名と参照名(LIST選択オプション)の間のコマンドオプションのparenthesizedリストを加える、任意
Leiba & Melnikov Standards Track [Page 4] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[4ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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リターンオプション)のリスト。 セクション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応答で認識しないオプションに反応しなければなりません。 クライアントSHOULD NOTは一度よりどんなオプションで指定します。 しかしながら、クライアントがこれをするなら、まるで一度だけオプションを受け取るかのようにサーバは行動しなければなりません。 オプションがクライアントによって指定されるオーダーは重要ではありません。
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選択オプションは、この点で異常であり、対応するリターンオプションを持っていません。 それはそれが返されるメールボックスのセットを制限するよりむしろ膨張させるからです。 この仕様への今後の拡大は、平行関係を覚えておいて、1組の対応するオプションを定義するべきです。
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
この拡大は能力ストリングによって「リストで、広げられた」状態で特定されます、そして、それのサポートはリストコマンドの専門化しているフォームを必要とするどんな将来の拡張子のための前提条件です。 そのような拡大は、このドキュメントを参照しなければならなくて、ここに説明されるようにコマンドオプションでそれらの機能を加えなければなりません。 その拡大に注意してください。
Leiba & Melnikov Standards Track [Page 5] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[5ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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コマンドに支持を要しないでくださいが、使用がLIST応答を広げたのが(以下を見てください)「リストで広げられた」能力ストリングの広告を出す必要はありません。
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応答と拡大を定義します、終わり(タグ付けをされたデータ(また、「拡張データ項目」と呼ばれる)のparenthesizedリスト)の一連の拡張分野を許容して 拡張分野の最初の要素はタグです。(そのタグはデータのタイプを特定します)。 このドキュメントのセクション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:
\、実在しなさ、」 属性は、メールボックス名が既存のメールボックスについて言及しないのを示します。 この属性がそれ自体で重要でないことに注意してください、また、以下にリストアップされた2つの状態の1つを満たさない場合正準なLISTパターンを合わせますが、存在しないメールボックス名を返してはいけないとき:
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パターンを合わせないで、選択評価基準に合っている少なくとも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).
「実際には、これがそれを意味する、」、\実在しない、」 属性が通常、1と共に返されるか、または」 さらに\について申し込まれる、」、」、\リモートである、」、」、」 \HasChildren CHILDINFOはデータ項目を広げました(以下での彼らの記述を見てください)。
Leiba & Melnikov Standards Track [Page 6] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[6ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" attribute MUST be supported and MUST be accurately computed.
\、実在しなさ、」 属性が」 \NoSelectを含意する、」 \、実在しなさ、」 属性をサポートしなければならなくて、正確に計算しなければなりません。
3.1. Initial List of Selection Options
3.1. 選択オプションの初期のリスト
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)".
SUBSCRIBED--LISTが記載すると命令する原因は既存のメールボックスよりむしろ名前を申し込みました。 これはしばしば実際のメールボックスの部分集合になるでしょう。 また、このリストが存在しないメールボックスの名前を含むのも、可能です。 どのような場合でも、リストはまさに正準なリストパターンを合わせて、加入されるそれらのメールボックス名を含まなければなりません。 このオプションがLSUBコマンドを補うことを意図します。 特定では、LSUBによって返されるものと比べて、注意はこのオプションで返すようにメールボックス属性です。 後者で、返された属性はメールボックス名の実際の属性状態を反映しないかもしれません、そして、NoSelectが結果と考える\は第2の特別な意味を持っています(このメールボックスがそうでないことを示します、それ自体、下降のメールボックスを持っていなかったなら申し込まれて)。 SUBSCRIBED選択オプションがここで説明されている状態で、属性は、正確であって、完全であり、どんな特別な意味も持っていません。 その結果、"LSUB"と「リスト(申し込まれる)」は同じものではありません、そして、いくつかのサーバが「記載(申し込まれます)」ために応じるために重要な時間外労働をしなければなりません。 これのために、彼らが明確に「リスト(申し込まれる)」で追加情報を提供して欲しくないなら、クライアントSHOULDは、"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選択オプションが指定されるとき、サポートしなければならなくて、正確に計算しなければなりません。
Note that the SUBSCRIBED selection option implies the SUBSCRIBED
return option (see below).
SUBSCRIBED選択オプションが、SUBSCRIBEDがオプションを返すのを(以下を見てください)含意することに注意してください。
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コマンドを引き起こします。 このオプションがRLISTコマンドを置き換えることを意図して、SUBSCRIBED選択オプションに関連して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オプションが指定されるとき、正確に属性を計算しなければなりません。
The REMOTE selection option has no interaction with other options.
Its effect is to tell the server to apply the other options, if
REMOTE選択オプションには、別の選択肢との相互作用が全くありません。 効果は別の選択肢を適用するようにサーバに言うことです。
Leiba & Melnikov Standards Track [Page 7] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[7ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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)を求める要求は無効です。 (REMOTE RECURSIVEMATCH SUBSCRIBED)がすべてを求めているので、要求は地方のものと同様にリモートなメールボックスを申し込みました。
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.
CHILDINFOがデータ項目を広げたとき、RECURSIVEMATCHオプションが指定されても、クライアントがまだケースを扱うことができなければならないというメモを返します、そして、その後のLISTコマンドの選択評価基準を満たす「副-メールボックス」が全くありません、LIST応答を送った後にもかかわらず、クライアントにそれらにアクセスする機会がある前を除いて、それらを削除するか、または改名できるように。
3.2. Initial List of Return Options
3.2. リターンオプションの初期のリスト
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--LISTが購読を返すと命令する原因はすべての合っているメールボックスのために名前を述べます。 \は」 属性を申し込みました。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.
CHILDREN--メールボックス子供情報が同じくらい元々[CMbox]で提案した要求。 以下で詳細に関してセクション4を見てください。 このオプションはすべてのサーバで後押しされていなければなりません。
Leiba & Melnikov Standards Track [Page 8] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[8ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
3.3. General Principles for Returning LIST Responses
3.3. 戻っているリスト応答のための綱領
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パターンに合っていない少なくとも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.
本件の詳しい情報に関しては、CHILDINFOがセクション3.5で説明されたデータ項目を広げたのを確実にしてください。 RECURSIVEMATCH選択オプションを指定するときだけ、CHILDINFOがデータ項目を広げたというメモを返すことができます。
3. Attributes returned in the same LIST response must be treated
additively. For example, the following response
3. 添加物に同じLIST応答で返された属性を扱わなければなりません。 例えば、以下の応答
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * 「リスト、(\が\を申し込んだ、実在しなさ、)、」 /、」 「果物/モモ」
means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed.
「果物/桃色」のメールボックスが存在していませんが、それが申し込まれることを意味します。
3.4. Additional Requirements on LIST-EXTENDED Clients
3.4. リストで拡張しているクライアントに関する追加要件
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が結果と考える\の存在を扱わなければなりません。
Leiba & Melnikov Standards Track [Page 9] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[9ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
The following table summarizes inference rules described in Section 3.
以下のテーブルはセクション3で説明された推論規則をまとめます。
+--------------------+-------------------+
| returned attribute | implied attribute |
+--------------------+-------------------+
| \NoInferiors | \HasNoChildren |
| \NonExistent | \NoSelect |
+--------------------+-------------------+
+--------------------+-------------------+ | 返された属性| 暗示している属性| +--------------------+-------------------+ | \NoInferiors| \HasNoChildren| | \実在しません。| \NoSelect| +--------------------+-------------------+
3.5. CHILDINFO Extended Data Item
3.5. CHILDINFOはデータ項目を広げました。
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応答でそれがそれを引き起こした選択評価基準について説明するデータを広げていて、メールボックスには選択評価基準に合っている少なくとも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.
」 \NoSelectはそれをしてはいけませんしかし、」 属性、LIST(SUBSCRIBED)が、命令する、」 \NoSelect以来。「LSUBコマンドが使用することによってこの状態を示す、」 ここで原義を保有します。 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」はメールボックス「顧客」が存在していない間、存在できます。 「RECURSIVEMATCH選択オプションが指定されないなら、CHILDINFOが広がったので、データ項目は許容されていません、そのようなサーバSHOULD使用、」 」 属性が選択評価基準に合っている下降のメールボックスがあるとクライアントに合図するために対にする\実在しない\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.
返された選択評価基準で、クライアントは、求められていないものと請求された応答を区別して、異なった評価基準を指定する複数のpipelined 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.
また、少なくとも1人の合っている子供が返されないなら、サーバSHOULD ONLYはCHILDINFOに伴う非合っているメールボックス名を返します。 すなわち、サーバSHOULDは余分な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、」 結果と考えます。
Leiba & Melnikov Standards Track [Page 10] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[10ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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 | +--------+--------------+--------------------+----------------------+
+--------+--------------+--------------------+----------------------+ | 存在しています。| 会う| 子供には、それがいます。| 戻ります。| | | 選択| 会う| リストで、広げられます。| | | 評価基準| 選択評価基準| そして属性。| | | | | CHILDINFO| +--------+--------------+--------------------+----------------------+ | いいえ| いいえ| いいえ| LIST応答がありません。| | | | | 戻ります。| | はい| いいえ| いいえ| LIST応答がありません。| | | | | 戻ります。| | いいえ| はい| いいえ| (\実在しない、| | | | | <attr>、) | | はい| はい| いいえ| (<attr>) | | いいえ| いいえ| はい| (\実在しません)です。 + | | | | | CHILDINFO| | はい| いいえ| はい| () + CHILDINFO| | いいえ| はい| はい| (\実在しない、| | | | | <attr>、) + CHILDINFO| | はい| はい| はい| (<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であるか、そして、選択評価基準に対応するより多くの属性。 例えば、SUBSCRIBEDオプションのために、<attr>は\Subscribedです。
4. The CHILDREN Return Option
4. 子供はオプションを返します。
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.
CHILDRENリターンオプションは元々マイクロソフト社のマイクGahrnsとレイモンド・チェンによって提案されたChild Mailbox Extensionを実行します。 このセクションの情報の大部分は直接それらの正式仕様書[CMbox]から抜粋されます。 CHILDRENリターンオプションは単にクライアントがこの情報が欲しいという指示です。 オプションが指定されないでも、サーバはそれを提供するかもしれません。
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
多くのIMAP4[IMAP4]クライアントがユーザが近づく手段を持っているメールボックスの階層的な視点をユーザに提示します。 初めは全体のメールボックス階層構造をユーザに提示するよりむしろ、メールボックス階層構造の潰れているアウトラインリストをユーザに見せているのはしばしば望ましいです(特に多くのメールボックスがあれば)。 そして、ユーザは必要に応じて潰れているアウトライン階層構造を広げることができます。 特定のメールボックスの下に子供メールボックスがあるのを示すために、潰れている階層構造の中に視覚手がかり(「+」などの)を含んでいるのは一般的です。 視覚手がかりはいつですか。
Leiba & Melnikov Standards Track [Page 11] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[11ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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.
クリックされていて、階層構造リストは、子供メールボックスを見せているために広げられます。 クライアントが、特定のメールボックスには子供がいるかどうかと効率的に決心するように、CHILDRENリターンオプションはメカニズムを提供します、LISTを発行しないで「「*かリスト、「「それぞれのメールボックス名のための%。」 CHILDRENリターンオプションはLIST応答の中で返さなければならない2つの新しい属性を定義します: \HasChildrenと\HasNoChildren。 どんなLISTコマンドに対応してこれらの属性を返すかもしれませんが、クライアントが特にこの情報が欲しいのを示すためにCHILDRENリターンオプションを提供します。 CHILDRENリターンオプションが存在しているなら、彼らの計算が高価であっても、サーバはこれらの属性を返さなければなりません。
\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.
この属性の存在は、メールボックスには子供メールボックスがあるのを示します。 子供メールボックスがあれば、サーバSHOULD NOTはこの属性を設定しました、そして、ユーザには、それらのどれかにアクセスする許可がありません。 この場合\HasNoChildren SHOULD、使用されてください。 多くの場合、しかしながら、ユーザがどんな子供メールボックスにも近づく手段を持っているか否かに関係なく、サーバは効率的に計算できないかもしれません。 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.
それはサーバが同じLIST応答における、\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に混乱するべきではありません、そして、将来、なにも作成できません。(NoInferiorsは子供メールボックスが全く現在存在しないのを示します)。
Leiba & Melnikov Standards Track [Page 12] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[12ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
5. Examples
5. 例
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が記載する、「「「*」S:」 * 「」 /を記載してください(\は、\がNoInferiorsであるとマークしました)」という「受信トレイ」S: * 「() 」 /を記載してください」という「果物」S: * 」 「リスト()」/「果物/アップル」S: * 「() 」 /を記載してください」という「果物/バナナ」S: * 「() 」 /を記載してください」という「豆腐」S: * 「() 」 /を記載してください」という「野菜」S: * 「() 」 /を記載してください」という「野菜/ブロッコリー」S: * 「() 」 /を記載してください」という「野菜/とうもろこし」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人の子供がいます。 また、それらの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
C: A02が記載する、(申し込まれます)「「「*」S:」 * 「」 /を記載してください(NoInferiors\が申し込んだ\であるとマークされた\)」という「受信トレイ」S: * 「」 /を記載してください(\は申し込まれました)」という「果物/バナナ」S: * 「リスト、(\が\を申し込んだ、実在しなさ、)、」 /、」 「果物/モモ」S: * 「」 /を記載してください(\は申し込まれました)」という「野菜」S: * 「」 /を記載してください(\は申し込まれました)」という「野菜/ブロッコリー」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: 次の例はCHILDRENオプションの使用を示しています。 第2レベルの階層構造を記載する必要はなくて、クライアントは今、トップレベルメールボックスのどれに「副-メールボックス」(子供)があるか、そして、どれが持っていないかを知っています。 サーバが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が()を記載する、「「「%」は(子供)Sを返します」。 * 「」 /を記載してください(\は、\がNoInferiorsであるとマークしました)」という「受信トレイ」S: * 「」 (\HasChildren)/を記載してください」という「果物」S: * 「」 (\HasNoChildren)/を記載してください」という「豆腐」S: * 「」 (\HasChildren)/を記載してください」という「野菜」S: 行われたA03 OK
Leiba & Melnikov Standards Track [Page 13] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[13ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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が記載する、(リモート)「「「%」は(子供)Sを返します」。 * 「」 /を記載してください(\は、\がNoInferiorsであるとマークしました)」という「受信トレイ」S: * 「」 (\HasChildren)/を記載してください」という「果物」S: * 「」 (\HasNoChildren)/を記載してください」という「豆腐」S: * 「」 (\HasChildren)/を記載してください」という「野菜」S: * 「」 /を記載してください(\リモートな)」という「パン」S: * 「」 /を記載してください(\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が記載する、(リモートである、申し込み、)、「「「*」S:」 * 「」 /を記載してください(NoInferiors\が申し込んだ\であるとマークされた\)」という「受信トレイ」S: * 「」 /を記載してください(\は申し込まれました)」という「果物/バナナ」S: * 「リスト、(\が\を申し込んだ、実在しなさ、)、」 /、」 「果物/モモ」S: * 「」 /を記載してください(\は申し込まれました)」という「野菜」S: * 「」 /を記載してください(\は申し込まれました)」という「野菜/ブロッコリー」S: * 「」 /を記載してください(リモート\が申し込んだ\)」という「パン」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".
このコマンドの出力が前の例における出力のスーパーセットでないことに注意してください、実在しない「果物/モモ」のためのLIST応答を含んでいないとき。
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が記載する、(リモート)「「「*」リターン(申し込まれる)S:」 * 「」 /を記載してください(NoInferiors\が申し込んだ\であるとマークされた\)」という「受信トレイ」S: * 「() 」 /を記載してください」という「果物」S: * 」 「リスト()」/「果物/アップル」S: * 「」 /を記載してください(\は申し込まれました)」という「果物/バナナ」S: * 「() 」 /を記載してください」という「豆腐」S: * 「」 /を記載してください(\は申し込まれました)」という「野菜」S: * 「」 /を記載してください(\は申し込まれました)」という「野菜/ブロッコリー」S: * 「() 」 /を記載してください」という「野菜/とうもろこし」S: * 「」 /を記載してください(リモート\が申し込んだ\)」という「パン」S: * 「」 /を記載してください(\リモートな)」という「肉」S: 行われたA06 OK
Leiba & Melnikov Standards Track [Page 14] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[14ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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が記載する、「「(「受信トレイ」「草稿」は「%を/に送った」)S:」 * 「() 」 /を記載してください」という「受信トレイ」S: * 「」 (\NoInferiors)/を記載してください」という「草稿」S: * 「() 」 /を記載してください」という「/March2004を送った」というS、: * 「」 (マークされた\)/を記載してください」という「/December2003を送った」というS、: * 「() 」 /を記載してください」という「/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が記載する、「「「*」S:」 * 「」 /を記載してください(\は、\がNoInferiorsであるとマークしました)」という「受信トレイ」S: * 」 「リスト()」/"Foo"S: * 」 「リスト()」/「Foo/バー」S: * 「リスト()」/」 「Foo/バズ」S: * 「() 」 /を記載してください」という「もー」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が記載する、「「「%」は(子供)Sを返します」。 * 「」 /を記載してください(\は、\がNoInferiorsであるとマークしました)」という「受信トレイ」S: * 」 「リスト(\HasChildren)」/"Foo"S: * 「」 (\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が記載する、(申し込まれます)「「「*」S:」 * 「リスト(\は申し込まれた)」/」 「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(SUBSCRIBED)を発行する、「「「%、「>、サーバはメールボックスを全く返メールボックス「もー」、"Foo"、および「受信トレイ」が申し込まれないとき()でないでしょう」。 しかしながら、クライアントがこれを発行するなら:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
C: C04が記載する、(RECURSIVEMATCHを申し込みます)「「「%」S:」 * 「リスト()」/」 "Foo"("CHILDINFO"(「申し込まれる」))S: 行われたC04 OK
Leiba & Melnikov Standards Track [Page 15] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[15ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
(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
C: C04が記載する、(RECURSIVEMATCHを申し込みます)「「「%」S:」 * 「リスト(\は申し込まれた)」/」 "Foo"("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が記載する、(RECURSIVEMATCHを申し込みます)「「「%」S:」 * 「リスト(\は\HasChildrenを申し込んだ)」/」 "Foo"("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:
A2) 私たちが、メールボックス"Foo"が元の階層構造の一部でなく、また申し込まれないと代わりに思うと、持続コマンドはこの結果を与えるでしょう:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
C: C04が記載する、(RECURSIVEMATCHを申し込みます)「「「%」S:」 * 「リスト(\実在しない)」/」 "Foo"("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(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"と「もー」だけ、が申し込まれると仮定してください。 その場合、私たちはこの結果を見ます:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done
C: C04が記載する、(RECURSIVEMATCHを申し込みます)「「「%」は(子供)Sを返します」。 * 」 「リスト(HasChildren\が申し込んだ\)」/"Foo"S: * 「」 /を記載してください(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: 以下の例は、子供メールボックスが正準なLISTパターンに合っているか否かに関係なく、CHILDINFOが商品が返されるデータを広げたのを示します。
Leiba & Melnikov Standards Track [Page 16] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[16ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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が記載する、「「「*」S:」 * 「」 /を記載してください(\は、\がNoInferiorsであるとマークしました)」という「受信トレイ」S: * 「() 」 /を記載してください」、「foo2" S:」 * 「() 」 /を記載してください」、「foo2/bar1"S:」 * 「() 」 /を記載してください」、「foo2/bar2"S:」 * 「() 」 /を記載してください」、「baz2" S:」 * 「() 」 /を記載してください」、「baz2/bar2"S:」 * 「() 」 /を記載してください」、「baz2/bar22"S:」 * 」 「リスト()」/"baz2/bar222"S: * 「() 」 /を記載してください」、「eps2" S:」 * 」 「リスト()」/「eps2/マンバ」S: * 「() 」 /を記載してください」、「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が記載する、(申し込まれます)「「「*」S:」 * 「」 /を記載してください(\は申し込まれました)」、「foo2/bar1"S:」 * 「」 /を記載してください(\は申し込まれました)」、「foo2/bar2"S:」 * 「」 /を記載してください(\は申し込まれました)」、「baz2/bar2"S:」 * 「」 /を記載してください(\は申し込まれました)」、「baz2/bar22"S:」 * 」 「リスト(\は申し込まれた)」/"baz2/bar222"S: * 「」 /を記載してください(\は申し込まれました)」、「eps2" S:」 * 」 「リスト(\は申し込まれた)」/「eps2/マンバ」S: * 「」 /を記載してください(\は申し込まれました)」、「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が記載する、(RECURSIVEMATCHは申し込みました)「「「*2インチS:」 * 「() 」 /を記載してください」、「foo2"("CHILDINFO"(「申し込まれる」))S:」 * 「」 /を記載してください(\は申し込まれました)」、「foo2/bar2"S:」 * 「」 /を記載してください(\は申し込まれました)」、「baz2/bar2"S:」 * 「」 /を記載してください(\は申し込まれました)」、「baz2/bar22"S:」 * 」 「リスト(\は申し込まれた)」/"baz2/bar222"S: * 「」 /を記載してください(\は申し込まれました)」、「eps2"("CHILDINFO"(「申し込まれる」))S:」 * 「」 /を記載してください(\は申し込まれました)」、「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でSHOULD NOTに違反するでしょう)
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
S: * 「() 」 /を記載してください」、「baz2"("CHILDINFO"(「申し込まれる」))S:」 * 」 「リスト(\実在しない)」/"qux2""("CHILDINFO"(「申し込まれます」))
Leiba & Melnikov Standards Track [Page 17] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[17ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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"、メールボックスのために子供を申し込んだ、「2人の申し込まれた子供のひとりだけのfoo2"はパターンに合っています、メールボックスのために「すべての申し込まれた子供の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が記載する、(RECURSIVEMATCHは申し込みました)「「「*」S:」 * 「() 」 /を記載してください」、「foo2"("CHILDINFO"(「申し込まれる」))S:」 * 「」 /を記載してください(\は申し込まれました)」、「foo2/bar1"S:」 * 「」 /を記載してください(\は申し込まれました)」、「foo2/bar2"S:」 * 「() 」 /を記載してください」、「baz2"("CHILDINFO"(「申し込まれる」))S:」 * 「」 /を記載してください(\は申し込まれました)」、「baz2/bar2"S:」 * 「」 /を記載してください(\は申し込まれました)」、「baz2/bar22"S:」 * 」 「リスト(\は申し込まれた)」/"baz2/bar222"S: * 「」 /を記載してください(\は申し込まれました)」、「eps2"("CHILDINFO"(「申し込まれる」))S:」 * 」 「リスト(\は申し込まれた)」/「eps2/マンバ」S: * 「」 /を記載してください(\は申し込まれました)」、「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.
メールボックスのためのLIST応答、「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: a1 LIST、「「("foo"「foo/*」)S:」 * 」 「LIST()」/foo S: 行われたa1OK
C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done
C: a2 LIST(SUBSCRIBED)、「「「foo/*」S:」 * 」 「LIST(\Subscribed\NonExistent)」/foo/バーS: 行われたa2OK
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: a3 OK done
C: a3 LIST(SUBSCRIBED RECURSIVEMATCH)、「「fooリターン(子供)S:」 * fooである("CHILDINFO"(「申し込まれる」))「LIST(\HasNoChildren)」/、S: 行われたa3OK
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選択オプションを指定しなかったクライアントに合図できるかに示します。
Leiba & Melnikov Standards Track [Page 18] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[18ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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(\Remote)」/、」 /ジャズSも: 行われたa1OK
C: a2 LIST () "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: a2 OK done
C: a2 LIST()、「「%S:」 * 「LIST(\NonExistent\HasChildren)」/、」 音楽S: 行われたa2OK
C: a3 LIST (REMOTE) "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: * LIST (\NonExistent \HasChildren) "/" also
S: a3 OK done
C: a3 LIST(REMOTE)、「「%S:」 * 「LIST(\NonExistent\HasChildren)」/、」 音楽S: * 「LIST(\NonExistent\HasChildren)」/、」 Sも: 行われたa3OK
C: a3.1 LIST "" (% music/rock)
S: * LIST () "/" music/rock
S: a3.1 OK done
C: a3.1 LIST、「「(%音楽/岩石)S:」 * 」 音楽/が強く揺すぶる「LIST()」/、S: 行われたa3.1OK
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.
「音楽/岩石」が「音楽」の下で唯一のメールボックスであるので、またサーバが「音楽」を返す必要は全くありません。 しかしながら、クライアントは両方のケースを扱わなければなりません。
6. Formal Syntax
6. 正式な構文
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]で説明されるようにAugmented BN記法(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の如何にかかわらず標準化過程を前方へ動くことができるドキュメントで。
Leiba & Melnikov Standards Track [Page 19] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[19ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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.
「(「引用されて、選んだベースが選ぶリスト*(引用されて、選んだベースが選ぶSPリスト)」)」というchildinfoが項目を拡張している="CHILDINFO"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、」、。 CHILDRENのための属性は最も1つでオプションを返します。 LIST応答単位で可能です。
eitem-standard-tag = atom
; a tag for extended list data defined in a Standard
; Track or Experimental RFC.
eitemの標準のタグは原子と等しいです。 Standardで定義された拡張リストデータのためのタグ。 道か実験的な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]
=「リスト」を記載してください、[SP、リスト選ぶ、選ぶ、]、SPのメールボックスのSP mboxか軽くたたくこと[リターンが選ぶSPリスト]
list-return-opts = "RETURN" SP
"(" [return-option *(SP return-option)] ")"
; list return options, e.g., CHILDREN
「(「[リターンオプション*(SPリターンオプション)]」)」というリストリターンが選ばれた=「リターン」SP。 リストリターンオプション、例えば、CHILDREN
list-select-base-opt = "SUBSCRIBED" / option-extension
; options that can be used by themselves
選んだベースが選ぶリストはオプション「申し込み」/拡大と等しいです。 自分たちで使用できるオプション
list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
引用されて、選んだベースが選ぶリストはDQUOTE選んだベースが選ぶリストDQUOTEと等しいです。
list-select-independent-opt = "REMOTE" / option-extension
; options that do not syntactically interact with
; other options
選んだ独立者が選ぶリストはオプション「リモート」/拡大と等しいです。 それがシンタクス上対話しないオプション。 別の選択肢
list-select-mod-opt = "RECURSIVEMATCH" / option-extension
; options that require a list-select-base-opt
; to also be present
選んだモッズが選ぶリストはオプション"RECURSIVEMATCH"/拡大と等しいです。 選んだベースが選ぶリストを必要とするオプション。 また、存在しているように
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.
リスト選ぶ、選ぶ、選んだモッズが選ぶ選んだ独立者が選ぶ選んだベースが選ぶ=リスト/リスト/リスト。 登録テンプレートが説明されるオプション。 このドキュメントのセクション9.3。
Leiba & Melnikov Standards Track [Page 20] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[20ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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)
リスト選ぶ、選ぶ、等しさ、「(「(*、(リスト選ぶ、選ぶ、SP) 選んだベースが選ぶリスト*、(SP、リスト選ぶ、選ぶ、)、/(選んだ独立者が選ぶリスト*(選んだ独立者が選ぶSPリスト)]、」、)、」、。 いろいろなオプションが順不同であるかもしれません。 ; 選んだモッズが選ぶリストが現れるなら、そして、aです。 また、選んだベースが選ぶリストは現れなければなりません。 ; これはこれらを許容します: ; () ; (リモート)です。 ; (申し込まれます) ; (リモートな状態で、申し込まれます) ; (申し込まれたRECURSIVEMATCH) ; (申し込まれたリモートRECURSIVEMATCH) ; しかし、NOTはこれらを許容します: ; (RECURSIVEMATCH) ; (リモート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]
メールボックスリストはSP(DQUOTE QUOTED-CHAR DQUOTE/無)SPメールボックスと等しいです「(「[mbxリスト旗]」)」という[SP mboxリストは広がりました]。 これはABNFによって示されたリスト情報です。 「メールボックスデータ」という項目。(その項目は中で定義されます)。[IMAP4]
mbox-list-extended = "(" [mbox-list-extended-item
*(SP mbox-list-extended-item)] ")"
「(「[mboxにリスト拡張している項目*(SP mboxは拡張項目を記載する)]」)」という広げられた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オプション価値]
Leiba & Melnikov Standards Track [Page 21] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[21ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
option-standard-tag = atom
; an option defined in a Standards Track or
; Experimental RFC
オプションの標準のタグは原子と等しいです。 または、オプションがStandards Trackで定義した、。 実験的なRFC
option-val-comp = astring /
option-val-comp *(SP option-val-comp) /
"(" option-val-comp ")"
「(「オプションvalコンピュータ」)」というオプションvalコンピュータ=オプションval astring/コンピュータ*(SPオプションvalコンピュータ)/
option-value = "(" option-val-comp ")"
オプション価値は「(「オプションvalコンピュータ」)」と等しいです。
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
リターンオプションはオプション「申し込み」/「子供」/拡大と等しいです。
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コンピュータ=タグ付けをされたext astring/コンピュータ*、(SP、タグ付けをされたextコンピュータ) 「(「タグ付けをされたextコンピュータ」)」という/。 この一般に続く拡大。 の代わりにする、構文がnstringを使用するべきである、。 文脈で適切であるときに、astringします。 拡大について。 ; そのメッセージセットか「数」に注意してください。 「原子」としていつも表すことができます。 ; URLが表されるべきである、。 「引用された」ストリング。
tagged-ext-simple = sequence-set / number
簡単な状態でextにタグ付けををしている=シーケンスセット/番号
tagged-ext-val = tagged-ext-simple /
"(" [tagged-ext-comp] ")"
ext簡単な状態でタグ付けをされて、タグ付けをされたext-valが等しい、「(「[タグ付けをされたextコンピュータ]」)」という/
7. Internationalization Considerations
7. 国際化問題
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への今後の拡大は、より洗練されたテストをする選択オプションを定義するかもしれません。 COMPARATOR[I18N]拡張子があるときテキストを合わせるのを必要とするテストの場合では、比較するのにアクティブな比較器を使用しなければなりません。 そのようなLIST-EXTENDED拡張子はそれらの仕様でCOMPARATOR[I18N]拡張子との相互作用を示さなければなりません。
Leiba & Melnikov Standards Track [Page 22] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[22ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
8. Security Considerations
8. セキュリティ問題
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コマンドには、それらのコマンドと同じセキュリティ問題があります。 それらは[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は特定のメールボックスには子供がいるかどうか決定するより効率的な手段をクライアントに提供します。 メールボックスには子供がいますが、現在認証されたユーザが彼らのいずれにも近づく手段を持っていないなら、サーバSHOULDは\HasNoChildren属性で応じます。 多くの場合、しかしながら、ユーザがどんな子供メールボックスにも近づく手段を持っているか否かに関係なく、サーバは効率的に計算できないかもしれません。 事実上、現在認証されたユーザがどんな子供メールボックスにも近づく手段を持っていないとき、そのようなサーバが\HasChildren属性で反応するなら、潜在的により多くの情報が意図するよりメールボックスの周りで伝えられます。 ほとんどの状況で、これはセキュリティ関心でなくなるでしょう、メールボックスには子供がいるかどうかの情報が敏感であると考えられるなら、そのメールボックスへのユーザのアクセスは第一に承諾されないでしょう、したがって。
The CHILDINFO extended data item has the same security considerations as the \HasChildren attribute described above.
CHILDINFOは項目がHasChildren属性が説明した\と同じセキュリティ問題を持っているデータを広げました。
9. IANA Considerations
9. IANA問題
9.1. Guidelines for IANA
9.1. IANAのためのガイドライン
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つの新しい登録を作成しました。 テンプレートと初期の登録証明書は以下で詳細です。
9.2. Registration Procedure and Change Control
9.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 への電子メールを通してそれを送ることによって、LIST-EXTENDEDオプションの登録をします。 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,
「V」から始まるLIST-EXTENDEDオプション/拡張しているデータ項目名はベンダー特有のオプション/拡張しているデータ項目のために予約されます。それらがベンダー特有であるか、またはグローバルであることにかかわらずすべてのオプションがIANAに登録されるべきです。 LIST-EXTENDEDが広がったなら、特定のLIST-EXTENDEDオプションを要求することの結果、データ項目を返します。
Leiba & Melnikov Standards Track [Page 23] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[23ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
the name of the option SHOULD be used as the name of the LIST-EXTENDED extended data item.
名前、オプションSHOULDでは、LIST-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-EXTENDEDオプション/拡張しているデータ項目は正常な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メーリングリストに送るべきです。 コメントのSubmittersは、所有者に連絡する合理的な試みの後に彼らのコメントを登録自体に付けるよう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によって発表されたリストで明確にマークされるでしょう。
Leiba & Melnikov Standards Track [Page 24] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[24ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
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-EXTENDEDオプション/拡張しているデータ項目の所有者であると考えられます。
9.3. Registration Template for LIST-EXTENDED Options
9.3. 登録のテンプレートの繰返し要素の並びで拡張しているオプション
To: iana@iana.org Subject: Registration of LIST-EXTENDED option X
To: iana@iana.org Subject: LIST-EXTENDEDオプションXの登録
LIST-EXTENDED option name:
LIST-EXTENDEDオプション名:
LIST-EXTENDED option type: (One of SELECTION or RETURN)
LIST-EXTENDEDオプションタイプ: (1つ、選択かリターン)
Implied return options(s), if the option type is SELECTION: (zero or more)
含意されて、オプションタイプがSELECTIONであるならオプションを返してください: (ゼロか以上)
LIST-EXTENDED option description:
LIST-EXTENDEDオプション記述:
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:
詳細のために連絡する人とEメールアドレス:
Owner/Change controller:
所有者/変化コントローラ:
(Any other information that the author deems interesting may be added below this line.)
(作者がおもしろいと考えるいかなる他の情報もこの系列の下で加えられるかもしれません。)
9.4. Initial LIST-EXTENDED Option Registrations
9.4. 初期のリストで拡張しているオプション登録証明書
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. To: iana@iana.org Subject: LIST-EXTENDEDオプションSUBSCRIBEDの登録
LIST-EXTENDED option name: SUBSCRIBED
LIST-EXTENDEDオプション名: 申し込まれます。
LIST-EXTENDED option type: SELECTION
LIST-EXTENDEDオプションタイプ: 選択
Implied return options(s): SUBSCRIBED
暗示しているリターンオプション: 申し込まれます。
LIST-EXTENDED option description: Causes the LIST command to list
subscribed mailboxes, rather than the actual mailboxes.
LIST-EXTENDEDオプション記述: LISTが記載すると命令する原因は実際のメールボックスよりむしろメールボックスを申し込みました。
Leiba & Melnikov Standards Track [Page 25] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[25ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
Published specification: RFC 5258, Section 3.
広められた仕様: RFC5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティ問題: RFC5258、セクション8。
Intended usage: COMMON
意図している用法: 一般的
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
詳細のために連絡する人とEメールアドレス: Alexey Melnikov <Alexey.Melnikov@isode.com 、gt。
Owner/Change controller: iesg@ietf.org
所有者/変化コントローラ: iesg@ietf.org
2. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option REMOTE
2. To: iana@iana.org Subject: LIST-EXTENDEDオプションREMOTEの登録
LIST-EXTENDED option name: REMOTE
LIST-EXTENDEDオプション名: リモート
LIST-EXTENDED option type: SELECTION
LIST-EXTENDEDオプションタイプ: 選択
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.
LIST-EXTENDEDオプション記述: RFC2193で説明されるように地方のものと同様にリモートメールボックスを返すLISTコマンドを引き起こします。
Published specification: RFC 5258, Section 3.
広められた仕様: RFC5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティ問題: RFC5258、セクション8。
Intended usage: COMMON
意図している用法: 一般的
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
詳細のために連絡する人とEメールアドレス: Alexey Melnikov <Alexey.Melnikov@isode.com 、gt。
Owner/Change controller: iesg@ietf.org
所有者/変化コントローラ: iesg@ietf.org
3. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option SUBSCRIBED
3. To: iana@iana.org Subject: LIST-EXTENDEDオプションSUBSCRIBEDの登録
LIST-EXTENDED option name: SUBSCRIBED
LIST-EXTENDEDオプション名: 申し込まれます。
LIST-EXTENDED option type: RETURN
LIST-EXTENDEDオプションタイプ: リターン
LIST-EXTENDED option description: Causes the LIST command to
return subscription state.
LIST-EXTENDEDオプション記述: 購読状態を返すLISTコマンドを引き起こします。
Published specification: RFC 5258, Section 3.
広められた仕様: RFC5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティ問題: RFC5258、セクション8。
Leiba & Melnikov Standards Track [Page 26] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[26ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
Intended usage: COMMON
意図している用法: 一般的
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
詳細のために連絡する人とEメールアドレス: Alexey Melnikov <Alexey.Melnikov@isode.com 、gt。
Owner/Change controller: iesg@ietf.org
所有者/変化コントローラ: iesg@ietf.org
4. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH
4. To: iana@iana.org Subject: LIST-EXTENDEDオプションRECURSIVEMATCHの登録
LIST-EXTENDED option name: RECURSIVEMATCH
LIST-EXTENDEDオプション名: RECURSIVEMATCH
LIST-EXTENDED option type: SELECTION
LIST-EXTENDEDオプションタイプ: 選択
Implied return options(s): (none)
暗示しているリターンオプション: (なにも)
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.
広められた仕様: RFC5258、セクション3。
Security considerations: RFC 5258, Section 8.
セキュリティ問題: RFC5258、セクション8。
Intended usage: COMMON
意図している用法: 一般的
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
詳細のために連絡する人とEメールアドレス: Alexey Melnikov <Alexey.Melnikov@isode.com 、gt。
Owner/Change controller: iesg@ietf.org
所有者/変化コントローラ: iesg@ietf.org
5. To: iana@iana.org
Subject: Registration of LIST-EXTENDED option CHILDREN
5. To: iana@iana.org Subject: LIST-EXTENDEDオプションCHILDRENの登録
LIST-EXTENDED option name: CHILDREN
LIST-EXTENDEDオプション名: 子供
LIST-EXTENDED option type: RETURN
LIST-EXTENDEDオプションタイプ: リターン
LIST-EXTENDED option description: Requests mailbox child
information.
LIST-EXTENDEDオプション記述: メールボックス子供情報を要求します。
Published specification: RFC 5258, Section 3 and Section 4.
広められた仕様: RFC5258、セクション3、およびセクション4。
Security considerations: RFC 5258, Section 8.
セキュリティ問題: RFC5258、セクション8。
Intended usage: COMMON
意図している用法: 一般的
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
詳細のために連絡する人とEメールアドレス: Alexey Melnikov <Alexey.Melnikov@isode.com 、gt。
Leiba & Melnikov Standards Track [Page 27] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[27ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
Owner/Change controller: iesg@ietf.org
所有者/変化コントローラ: iesg@ietf.org
9.5. Registration Template for LIST-EXTENDED Extended Data Item
9.5. 登録のテンプレートの繰返し要素の並びで拡張している拡張データ項目
To: iana@iana.org Subject: Registration of X LIST-EXTENDED extended data item
To: iana@iana.org Subject: 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オプション(そして、彼らのタイプ)がこれを引き起こすかが返される(もしあれば)データ項目を広げました:
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:
詳細のために連絡する人とEメールアドレス:
Owner/Change controller:
所有者/変化コントローラ:
(Any other information that the author deems interesting may be added below this line.)
(作者がおもしろいと考えるいかなる他の情報もこの系列の下で加えられるかもしれません。)
9.6. Initial LIST-EXTENDED Extended Data Item Registrations
9.6. 初期のリストで拡張している拡張データ項目登録証明書
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. To: iana@iana.org Subject: 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オプション(そして、彼らのタイプ)がこれを引き起こすかが返される(もしあれば)データ項目を広げました: RECURSIVEMATCH選択オプション
Leiba & Melnikov Standards Track [Page 28] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[28ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
Published specification: RFC 5258, Section 3.5.
広められた仕様: RFC5258、セクション3.5。
Security considerations: RFC 5258, Section 8.
セキュリティ問題: RFC5258、セクション8。
Intended usage: COMMON
意図している用法: 一般的
Person and email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
詳細のために連絡する人とEメールアドレス: Alexey Melnikov <Alexey.Melnikov@isode.com 、gt。
Owner/Change controller: iesg@ietf.org
所有者/変化コントローラ: iesg@ietf.org
10. Acknowledgements
10. 承認
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とレイモンド・チェンは、元々、Child Mailbox Extensionについて工夫して、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、ティモSirainen、ケン・マーチソン、ロブSiemborski、スティーブHole、Arnt Gulbrandsen、ラリー・グリーンフィールド、デーヴCridland、およびピートマクレーンは、特に、それらの議論の積極的な参加者であったか提案をこのドキュメントにしました。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[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"、STD68、RFC5234、2008年1月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[ACAP] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255,
June 2008.
[I18N] ニューマンとC.とGulbrandsen、A.とA.メリニコフ、「インターネットメッセージアクセス・プロトコル国際化」、RFC5255、2008年6月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[Kwds]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
[MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
September 1997.
[MBRef] Gahrns、M.、「IMAP4メールボックス紹介」、RFC2193、1997年9月。
Leiba & Melnikov Standards Track [Page 29] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[29ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
11.2. Informative References
11.2. 有益な参照
[CMbox] Gahrns, M. and R. Cheng, "The Internet Message Action
Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
July 2002.
[CMbox]GahrnsとM.とR.チェン、「インターネットメッセージ動作プロトコル(IMAP4)子供メールボックス拡大」、RFC3348、2002年7月。
Authors' Addresses
作者のアドレス
Barry Leiba IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
バリーLeiba IBM T.J.ワトソン研究所19の地平線Driveニューヨーク10532ホーソーン(米国)
Phone: +1 914 784 7941 EMail: leiba@watson.ibm.com
以下に電話をしてください。 +1 7941年の914 784メール: leiba@watson.ibm.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
AlexeyメリニコフIsode株式会社5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス
EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/
メール: Alexey.Melnikov@isode.com ユリ: http://www.melnikov.ca/
Leiba & Melnikov Standards Track [Page 30] RFC 5258 IMAP4 LIST Command Extensions June 2008
Leibaとメリニコフ標準化過程[30ページ]RFC5258IMAP4はコマンド拡大2008年6月に記載します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Leiba & Melnikov Standards Track [Page 31]
Leibaとメリニコフ標準化過程[31ページ]
一覧
スポンサーリンク
