Network Working Group M. Crispin
Request for Comments: 5256 Panda Programming
Category: Standards Track K. Murchison
Carnegie Mellon University
June 2008
Internet Message Access Protocol - SORT and THREAD 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views.
このドキュメントでは、基本レベルのサーバーベースのIMAPプロトコルへの拡張をソートし、スレッドを説明しています。これらの拡張機能は、ソートとねじの景色を眺めることができますIMAPクライアントの大幅な性能向上を提供します。
The SORT and THREAD extensions to the [IMAP] protocol provide a means of server-based sorting and threading of messages, without requiring that the client download the necessary data to do so itself. This is particularly useful for online clients as described in [IMAP-MODELS].
[IMAP]プロトコルのSORTとTHREAD拡張は、クライアントが自らこれを行うに必要なデータをダウンロードすることを必要とせずに、サーバーベースのソートやメッセージのスレッドの手段を提供します。 [IMAP-MODELS]で説明したように、これは、オンラインのクライアントのために特に有用です。
A server that supports the base-level SORT extension indicates this with a capability name which starts with "SORT". Future, upwards-compatible extensions to the SORT extension will all start with "SORT", indicating support for this base level.
基本レベルのSORT拡張をサポートするサーバは、「SORT」で始まる機能名でこれを示します。将来、SORT拡張に上位互換の拡張機能は、すべてこの基本レベルのサポートを示す、「SORT」で始まります。
A server that supports the THREAD extension indicates this with one or more capability names consisting of "THREAD=" followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions.
スレッド拡張機能をサポートするサーバは、「スレッド=」この文書に記載されているようにサポートされているスレッドアルゴリズム名続いからなる1または複数の機能名でこれを示しています。これは、将来の上位互換の拡張機能を提供します。
A server that implements the SORT and/or THREAD extensions MUST collate strings in accordance with the requirements of I18NLEVEL=1, as described in [IMAP-I18N], and SHOULD implement and advertise the I18NLEVEL=1 extension. Alternatively, a server MAY implement I18NLEVEL=2 (or higher) and comply with the rules of that level.
[IMAP-I18N]に記載、及びI18NLEVEL = 1拡張機能を実装し、広告するべきこととしてSORTおよび/またはスレッドの拡張を実装するサーバは、I18NLEVEL = 1の要求に応じて文字列を照合しなければなりません。代替的に、サーバはI18NLEVEL = 2（またはそれ以上）を実装し、そのレベルのルールを遵守するかもしれません。
Discussion: The SORT and THREAD extensions predate [IMAP-I18N] by several years. At the time of this writing, all known server implementations of SORT and THREAD comply with the rules of I18NLEVEL=1, but do not necessarily advertise it. As discussed in [IMAP-I18N] section 4.5, all server implementations should eventually be updated to comply with the I18NLEVEL=2 extension.
ディスカッション：SORTとTHREAD拡張は、数年で[IMAP-I18N]をさかのぼります。この記事の執筆時点では、SORTとTHREADのすべての既知のサーバーの実装はI18NLEVEL = 1のルールに準拠していますが、必ずしもそれを宣伝しないでください。 [IMAP-I18N]セクション4.5で議論するように、すべてのサーバーの実装は、最終的I18NLEVEL = 2拡張に準拠するように更新されるべきです。
Historical note: The REFERENCES threading algorithm is based on the [THREADING] algorithm written and used in "Netscape Mail and News" versions 2.0 through 3.0.
ヒストリカルノート：アルゴリズムをスレッド参照が「Netscapeのメールとニュース」のバージョン3.0を通じて2.0で書かれており、使用[THREADING]アルゴリズムに基づいています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
The word "can" (not "may") is used to refer to a possible circumstance or situation, as opposed to an optional facility of the protocol.
プロトコルのオプション機能とは対照的に、ワード（「できる」ではない）、可能な環境や状況を指すために使用される「ことができます」。
"User" is used to refer to a human user, whereas "client" refers to the software being run by the user.
「クライアント」は、ユーザによって実行されているソフトウェアを指し、一方、「ユーザー」は、人間のユーザを参照するために使用されます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。
Subject sorting and threading use the "base subject", which has specific subject artifacts removed. Due to the complexity of these artifacts, the formal syntax for the subject extraction rules is ambiguous. The following procedure is followed to determine the "base subject", using the [ABNF] formal syntax rules described in section 5:
被験体は、選別除去特定被写体アーチファクトを有する「ベースの件名」、使用スレッド。これらのアーティファクトの複雑さのために、被写体抽出ルールの正式な構文はあいまいです。以下の手順はセクション5で説明した[ABNF]正式な構文規則を使用して、「基本件名」を決定するために続いています。
(1) Convert any RFC 2047 encoded-words in the subject to [UTF-8] as described in "Internationalization Considerations". Convert all tabs and continuations to space. Convert all multiple spaces to a single space.
「国際化の考慮事項」に記載されているように（1）[UTF-8]に、対象における任意のRFC 2047符号化ワードを変換します。すべてのタブと継続がスペースに変換します。すべての複数のスペースは、1つのスペースに変換します。
(2) Remove all trailing text of the subject that matches the subj-trailer ABNF; repeat until no more matches are possible.
（2）SUBJ-トレーラABNFに一致する被験者のすべての後続のテキストを削除します。これ以上の一致が可能ですなくなるまで繰り返します。
(3) Remove all prefix text of the subject that matches the subj-leader ABNF.
（3）SUBJ-リーダーABNFに一致する対象のすべての接頭辞のテキストを削除します。
(4) If there is prefix text of the subject that matches the subj-blob ABNF, and removing that prefix leaves a non-empty subj-base, then remove the prefix text.
SUBJ-ブロブABNFと一致し、そのプレフィックスを除去して非空SUBJベースを離れる被写体のプレフィックステキストがある場合（4）、次いで、プレフィックステキストを削除します。
(5) Repeat (3) and (4) until no matches remain.
（5）を繰り返し（3）及び（4）は、マッチが残っていないまで。
Note: It is possible to defer step (2) until step (6), but this requires checking for subj-trailer in step (4).
注：ステップ（6）まで、（2）ステップを延期することが可能であるが、これは、ステップ（4）におけるSUBJトレーラーのチェックが必要です。
(6) If the resulting text begins with the subj-fwd-hdr ABNF and ends with the subj-fwd-trl ABNF, remove the subj-fwd-hdr and subj-fwd-trl and repeat from step (2).
結果として得られるテキストはSUBJ-FWD-HDR ABNFで始まりSUBJ-FWD-TRLのABNFで終了した場合（6）、SUBJ-FWD-HDRとSUBJ-FWD-TRLを除去し、ステップ（2）から繰り返します。
(7) The resulting text is the "base subject" used in the SORT.
（7）得られたテキストは、SORTで使用される「ベース対象」です。
All servers and disconnected (as described in [IMAP-MODELS]) clients MUST use exactly this algorithm to determine the "base subject". Otherwise, there is potential for a user to get inconsistent results based on whether they are running in connected or disconnected mode.
すべてのサーバーおよび（[IMAP-MODELS]に記載されているように）切断されたクライアントは、「基本件名」を決定するために、正確にこのアルゴリズムを使用しなければなりません。ユーザーは、彼らが接続または切断モードで実行されているかどうかに基づいて、一貫性のない結果を得るためにのためにそれ以外の場合は、可能性があります。
As used in this document, the term "sent date" refers to the date and time from the Date: header, adjusted by time zone to normalize to UTC. For example, "31 Dec 2000 16:01:33 -0800" is equivalent to the UTC date and time of "1 Jan 2001 00:01:33 +0000".
ヘッダ、UTCに正規化する時間帯によって調整：この文書で使用されるように、用語「送信日時」は、日付から日付と時刻を指します。例えば、「2000年12月31日夜04時01分33秒-0800」は、「2001年1月1日午後12時01分33秒0000」のUTCの日付と時間に相当します。
If the time zone is invalid, the date and time SHOULD be treated as UTC. If the time is also invalid, the time SHOULD be treated as 00:00:00. If there is no valid date or time, the date and time SHOULD be treated as 00:00:00 on the earliest possible date.
タイムゾーンが無効の場合は、日付と時刻はUTCとして扱われるべきです。時間も無効である場合は、時間00:00:00として扱われるべきです。有効な日付や時間がない場合は、日付と時刻は、可能な限り早期に午後12時00分00秒として扱われるべきです。
This differs from the date-related criteria in the SEARCH command (described in [IMAP] section 6.4.4), which use just the date and not the time, and are not adjusted by time zone.
これは、単に日付としない時間を使用し、時間帯によって調整されていない（[IMAP]セクション6.4.4に記載）SEARCHコマンドの日付関連基準とは異なります。
If the sent date cannot be determined (a Date: header is missing or cannot be parsed), the INTERNALDATE for that message is used as the sent date.
送信された日付が決定できない場合（日付：ヘッダが欠落しているか、解析できない）、そのメッセージのINTERNALDATEは、送信日として使用されます。
When comparing two sent dates that match exactly, the order in which the two messages appear in the mailbox (that is, by sequence number) is used as a tie-breaker to determine the order.
正確に一致する2つの送信された日付を比較する場合、2件のメッセージが（すなわち、シーケンス番号である）メールボックスに表示される順序は、順序を決定するために、タイブレーカとして使用されます。
These commands are extensions to the [IMAP] base protocol.
これらのコマンドは、[IMAP]ベースプロトコルの拡張機能です。
The section headings are intended to correspond with where they would be located in the main document if they were part of the base specification.
セクションの見出しは、それらがベース仕様の一部であった場合、彼らは、メインドキュメント内に配置される場所に対応するように意図されています。
BASE.6.4.SORT. SORT Command
BASE.6.4.SORT。 SORTコマンド
Arguments: sort program charset specification searching criteria (one or more)
引数：ソートプログラムの文字セットの指定の検索基準（1以上）
Data: untagged responses: SORT
データ：タグなし応答：SORT
Result: OK - sort completed NO - sort error: can't sort that charset or criteria BAD - command unknown or arguments invalid
結果：OK - ソートNO完成 - ソート・エラーは： - コマンド不明または引数無効BADその文字セットまたは基準を並べ替えることはできません
The SORT command is a variant of SEARCH with sorting semantics for the results. There are two arguments before the searching criteria argument: a parenthesized list of sort criteria, and the searching charset.
SORTコマンドは、結果を得るためのセマンティクスをソートすると、検索の変種です。ソート基準の括弧で囲まれたリスト、および検索文字セット：検索条件の引数の前に二つの引数があります。
The charset argument is mandatory (unlike SEARCH) and indicates the [CHARSET] of the strings that appear in the searching criteria. The US-ASCII and [UTF-8] charsets MUST be implemented. All other charsets are optional.
charset引数は必須です（SEARCHとは異なり）と、検索基準に表示される文字列の[CHARSET]を示します。 US-ASCIIと[UTF-8]文字セットを実装する必要があります。他のすべての文字セットはオプションです。
There is also a UID SORT command that returns unique identifiers instead of message sequence numbers. Note that there are separate searching criteria for message sequence numbers and UIDs; thus, the arguments to UID SORT are interpreted the same as in SORT. This is analogous to the behavior of UID SEARCH, as opposed to UID COPY, UID FETCH, or UID STORE.
代わりに、メッセージのシーケンス番号の一意の識別子を返すUID SORTコマンドもあります。メッセージシーケンス番号とUIDのための独立した検索条件があることに注意してください。従って、UID SORTの引数はSORTと同様に解釈されます。 UID COPYとは対照的に、これは、UIDは、FETCH、またはUIDストア、UID検索の動作に似ています。
The SORT command first searches the mailbox for messages that match the given searching criteria using the charset argument for the interpretation of strings in the searching criteria. It then returns the matching messages in an untagged SORT response, sorted according to one or more sort criteria.
SORTコマンドは、最初の検索条件内の文字列の解釈のためのcharset引数を使用して、指定された検索条件に一致するメッセージのためのメールボックスを検索します。これは、1つの以上のソート基準に従ってソートされたタグ無しSORT応答に一致するメッセージを返します。
Sorting is in ascending order. Earlier dates sort before later dates; smaller sizes sort before larger sizes; and strings are sorted according to ascending values established by their collation algorithm (see "Internationalization Considerations").
ソートは昇順です。以前の並べ替えの前に、後の日付をさかのぼります。小さいサイズの並べ替えの前に大きいサイズ。そして、文字列は、その照合アルゴリズムによって確立昇順値に従ってソート（「国際化の考慮事項」を参照）されています。
If two or more messages exactly match according to the sorting criteria, these messages are sorted according to the order in which they appear in the mailbox. In other words, there is an implicit sort criterion of "sequence number".
二つ以上のメッセージが正確に並べ替えの基準に従って一致した場合、これらのメッセージは、それらがメールボックスに表示される順序に従ってソートされています。言い換えれば、「シーケンス番号」の暗黙のソート基準があります。
When multiple sort criteria are specified, the result is sorted in the priority order that the criteria appear. For example, (SUBJECT DATE) will sort messages in order by their base subject text; and for messages with the same base subject text, it will sort by their sent date.
複数のソート条件を指定した場合、結果は基準が表示されている優先度順にソートされます。例えば、（被写体DATE）そのベース対象テキスト順にメッセージをソートします。そして、同じベース件名テキストとメッセージのために、それは彼らの送信日でソートされます。
Untagged EXPUNGE responses are not permitted while the server is responding to a SORT command, but are permitted during a UID SORT command.
タグなしEXPUNGE応答は、サーバがSORTコマンドに応答している間は許可されていませんが、UID SORTコマンドの実行中に許可されています。
The defined sort criteria are as follows. Refer to the Formal Syntax section for the precise syntactic definitions of the arguments. If the associated RFC-822 header for a particular criterion is absent, it is treated as the empty string. The empty string always collates before non-empty strings.
次のように定義されたソート基準はあります。引数の正確な構文定義について正式な構文のセクションを参照してください。特定の基準に関連付けられたRFC-822ヘッダが存在しない場合は、空の文字列として扱われます。空の文字列は、常に非空の文字列の前に照合します。
ARRIVAL Internal date and time of the message. This differs from the ON criteria in SEARCH, which uses just the internal date.
ARRIVAL内部日付やメッセージの時間。これは単に内部日付を使用する検索でON基準とは異なります。
CC [IMAP] addr-mailbox of the first "cc" address.
最初の "CC" アドレスのCC [IMAP] addrは、メールボックス。
DATE Sent date and time, as described in section 2.2.
セクション2.2で説明したようにDATEは、日付と時刻を送りました。
FROM [IMAP] addr-mailbox of the first "From" address.
アドレス「から」最初の[IMAP] addrは、メールボックスから。
REVERSE Followed by another sort criterion, has the effect of that criterion but in reverse (descending) order. Note: REVERSE only reverses a single criterion, and does not affect the implicit "sequence number" sort criterion if all other criteria are identical. Consequently, a sort of REVERSE SUBJECT is not the same as a reverse ordering of a SUBJECT sort. This can be avoided by use of additional criteria, e.g., SUBJECT DATE vs. REVERSE SUBJECT REVERSE DATE. In general, however, it's better (and faster, if the client has a "reverse current ordering" command) to reverse the results in the client instead of issuing a new SORT.
別のソート基準に続いREVERSE、その基準の効果が、逆に（降順）を有しています。注意：REVERSEは、単一の基準を反転させ、他のすべての基準が同一である場合、暗黙的な「シーケンス番号」ソート基準には影響を与えません。その結果、REVERSE SUBJECTの並べ替えは、被写体種類の逆の順序と同じではありません。これは、追加の基準、REVERSE対象REVERSEのDATE対例えば、SUBJECT DATEの使用によって回避することができます。 （クライアントは、「現在の順序を逆に」コマンドを持っている場合、そして速い）一般的に、しかし、それは代わりに新しいSORTを発行するクライアントに結果を逆にする方が良いでしょう。
SIZE Size of the message in octets.
オクテットでメッセージのSIZEサイズ。
SUBJECT Base subject text.
SUBJECTベース件名テキスト。
TO [IMAP] addr-mailbox of the first "To" address.
アドレス「から」最初の[IMAP] addrは、メールボックスに。
Example: C: A282 SORT (SUBJECT) UTF-8 SINCE 1-Feb-1994 S: * SORT 2 84 882 S: A282 OK SORT completed C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 ALL S: * SORT 5 3 4 1 2 S: A283 OK SORT completed C: A284 SORT (SUBJECT) US-ASCII TEXT "not in mailbox" S: * SORT S: A284 OK SORT completed
例：C：A282 SORT（SUBJECT）UTF-8が1-02月1994のS：* SORT 2 84 882 S：A282 OK SORT完了C：A283 SORT（SUBJECT逆DATE）UTF-8 ALL S：* SORT 5 3 4 1 2 S：A283 OK SORT完了C：A284 SORT（SUBJECT）US-ASCII TEXT "ではない、メールボックス内の" S：* SORTのS：A284 OK SORT完成
BASE.6.4.THREAD. THREAD Command
BASE.6.4.THREAD。 THREADコマンド
Arguments: threading algorithm charset specification searching criteria (one or more)
引数：アルゴリズムの文字セットの指定検索基準スレッド（1以上）
Data: untagged responses: THREAD
データ：タグなし応答：THREAD
Result: OK - thread completed NO - thread error: can't thread that charset or criteria BAD - command unknown or arguments invalid
結果：OK - スレッドが完了NO - スレッドエラー：BADその文字セットまたは基準をスレッドすることはできません - 無効なコマンド不明または引数
The THREAD command is a variant of SEARCH with threading semantics
for the results. Thread has two arguments before the searching
criteria argument: a threading algorithm and the searching
charset.
The charset argument is mandatory (unlike SEARCH) and indicates the [CHARSET] of the strings that appear in the searching criteria. The US-ASCII and [UTF-8] charsets MUST be implemented. All other charsets are optional.
charset引数は必須です（SEARCHとは異なり）と、検索基準に表示される文字列の[CHARSET]を示します。 US-ASCIIと[UTF-8]文字セットを実装する必要があります。他のすべての文字セットはオプションです。
There is also a UID THREAD command that returns unique identifiers instead of message sequence numbers. Note that there are separate searching criteria for message sequence numbers and UIDs; thus the arguments to UID THREAD are interpreted the same as in THREAD. This is analogous to the behavior of UID SEARCH, as opposed to UID COPY, UID FETCH, or UID STORE.
代わりに、メッセージのシーケンス番号の一意の識別子を返すUID THREADコマンドもあります。メッセージシーケンス番号とUIDのための独立した検索条件があることに注意してください。従ってUIDスレッドへの引数は、スレッドと同じ解釈されます。 UID COPYとは対照的に、これは、UIDは、FETCH、またはUIDストア、UID検索の動作に似ています。
The THREAD command first searches the mailbox for messages that match the given searching criteria using the charset argument for the interpretation of strings in the searching criteria. It then returns the matching messages in an untagged THREAD response, threaded according to the specified threading algorithm.
THREADコマンドは、最初の検索条件内の文字列の解釈のためのcharset引数を使用して、指定された検索条件に一致するメッセージのためのメールボックスを検索します。その後、指定されたスレッドアルゴリズムに従ってねじタグなしスレッド応答に一致するメッセージを返します。
All collation is in ascending order. Earlier dates collate before later dates and strings are collated according to ascending values established by their collation algorithm (see "Internationalization Considerations").
すべての照合が昇順です。後に日付や文字列は（「国際化の考慮事項」を参照）、その照合アルゴリズムによって確立された昇順の値に応じて照合される前に、以前の日付が照合します。
Untagged EXPUNGE responses are not permitted while the server is responding to a THREAD command, but are permitted during a UID THREAD command.
タグなしEXPUNGE応答は、サーバがTHREADコマンドに応答している間は許可されていませんが、UID THREADコマンドの中に許可されています。
The defined threading algorithms are as follows:
次のように定義されたスレッドアルゴリズムは以下のとおりです。
ORDEREDSUBJECT
ORDEREDSUBJECT
The ORDEREDSUBJECT threading algorithm is also referred to as "poor man's threading". The searched messages are sorted by base subject and then by the sent date. The messages are then split into separate threads, with each thread containing messages with the same base subject text. Finally, the threads are sorted by the sent date of the first message in the thread.
ORDEREDSUBJECTスレッドアルゴリズムはまた、「貧乏人のスレッド」と呼ばれています。検索メッセージは、ベース被験者によって、次に送ら日付順にソートされています。メッセージは、同じベース対象テキストのメッセージを含む各スレッドに、別のスレッドに分割されます。最後に、スレッドは、スレッドの最初のメッセージの送信日付でソートされています。
The top level or "root" in ORDEREDSUBJECT threading contains the first message of every thread. All messages in the root are siblings of each other. The second message of a thread is the child of the first message, and subsequent messages of the thread are siblings of the second message and hence children of the message at the root. Hence, there are no grandchildren in ORDEREDSUBJECT threading.
ORDEREDSUBJECTのスレッドでトップレベルまたは「ルート」は、すべてのスレッドの最初のメッセージが含まれています。ルート内のすべてのメッセージは、互いの兄弟です。スレッドの第2のメッセージは、最初のメッセージの子であり、スレッドのその後のメッセージは、第2のメッセージの兄弟、従ってルートにメッセージの子です。したがって、ORDEREDSUBJECTのスレッドには孫はありません。
Children in ORDEREDSUBJECT threading do not have descendents. Client implementations SHOULD treat descendents of a child in a server response as being siblings of that child.
ORDEREDSUBJECTスレッドの子どもたちが子孫を持っていません。クライアントの実装は、その子の兄弟であるとして、サーバ応答で子の子孫を扱うべきです。
REFERENCES
REFERENCES
The REFERENCES threading algorithm threads the searched messages by grouping them together in parent/child relationships based on which messages are replies to others. The parent/child relationships are built using two methods: reconstructing a message's ancestry using the references contained within it; and checking the original (not base) subject of a message to see if it is a reply to (or forward of) another message.
インクルードは、他の人への返信であるメッセージに基づいて、親/子関係でそれらを一緒にグループ化することによって、メッセージを検索するアルゴリズムのスレッドをスレッド参照。親/子関係は、2つのメソッドを使用して構築されています。その中に含まれている参照を使用してメッセージの祖先を再構築します。それは他のメッセージ（または順方向）への応答である場合、メッセージの元の（ない塩基）被写体を確認する確認してください。
Note: "Message ID" in the following description refers to a normalized form of the msg-id in [RFC2822]. The actual text in RFC 2822 may use quoting, resulting in multiple ways of expressing the same Message ID. Implementations of the REFERENCES threading algorithm MUST normalize any msg-id in order to avoid false non-matches due to differences in quoting.
注：以下の説明では「メッセージID」は、[RFC2822]にMSG-IDの正規化された形態を指します。 RFC 2822における実際のテキストは、同じメッセージIDを表現する複数の方法で得られた、引用使用してもよいです。アルゴリズムをスレッドREFERENCESの実装は、引用の違いによる偽の非マッチを避けるために、任意のMSG-IDを正規化しなければなりません。
For example, the msg-id <"01KF8JCEOCBS0045PS"@xxx.yyy.com> and the msg-id <01KF8JCEOCBS0045PS@xxx.yyy.com> MUST be interpreted as being the same Message ID.
例えば、MSG-ID < "01KF8JCEOCBS0045PS" @ xxx.yyy.com>とMSG-ID <01KF8JCEOCBS0045PS@xxx.yyy.com>は同じメッセージIDであると解釈されなければなりません。
The references used for reconstructing a message's ancestry are found using the following rules:
メッセージの祖先を再構築するために使用され参照は、以下のルールを使って発見されています。
If a message contains a References header line, then use the Message IDs in the References header line as the references.
メッセージが参照ラインヘッダが含まれている場合、その後、基準として参照ヘッダー行にメッセージIDを使用します。
If a message does not contain a References header line, or the References header line does not contain any valid Message IDs, then use the first (if any) valid Message ID found in the In-Reply-To header line as the only reference (parent) for this message.
メッセージが参照ヘッダー行が含まれていない、または参照ヘッダー行は、任意の有効なメッセージIDが含まれていない場合、その後に見出される（もしあれば）最初の有効なメッセージID、使用中-返信-する（参考として行ヘッダこのメッセージの親）。
Note: Although [RFC2822] permits multiple Message IDs in the In-Reply-To header, in actual practice this discipline has not been followed. For example, In-Reply-To headers have been observed with message addresses after the Message ID, and there are no good heuristics for software to determine the difference. This is not a problem with the References header, however.
注：[RFC2822]はイン返信先ヘッダに複数のメッセージIDを可能にするが、実際にこの規律が守られていません。例えば、ヘッダに、返信するためにメッセージIDの後にメッセージアドレスを用いて観察し、その差を決定するためのソフトウェアのための良好なヒューリスティックはありませんされています。しかし、これは、参照ヘッダの問題ではありません。
If a message does not contain an In-Reply-To header line, or the In-Reply-To header line does not contain a valid Message ID, then the message does not have any references (NIL).
メッセージは、In-返信先行ヘッダ、またはイン返信するには、有効なメッセージIDが含まれていない行ヘッダが含まれていない場合、そのメッセージは、任意の参照（NIL）を有していません。
A message is considered to be a reply or forward if the base subject extraction rules, applied to the original subject, remove any of the following: a subj-refwd, a "(fwd)" subj-trailer, or a subj-fwd-hdr and subj-fwd-trl.
SUBJ-refwd、「（FWD）」SUBJトレーラー、又はSUBJ-fwd-：メッセージが応答であるか、基地被写体抽出ルール場合に転送するように考えられている、以下のいずれかを削除、元の被験者に適用HDRとSUBJ-FWD-TRL。
The REFERENCES algorithm is significantly more complex than ORDEREDSUBJECT and consists of six main steps. These steps are outlined in detail below.
REFERENCESアルゴリズムはORDEREDSUBJECTよりもかなり複雑で、6つの主要なステップからなります。これらの手順は、以下に詳細に概説されています。
(1) For each searched message:
（1）各検索メッセージについて：
(A) Using the Message IDs in the message's references, link
the corresponding messages (those whose Message-ID
header line contains the given reference Message ID)
together as parent/child. Make the first reference the
parent of the second (and the second a child of the
first), the second the parent of the third (and the
third a child of the second), etc. The following rules
govern the creation of these links:
If a message does not contain a Message-ID header
line, or the Message-ID header line does not
contain a valid Message ID, then assign a unique
Message ID to this message.
If two or more messages have the same Message ID, then only use that Message ID in the first (lowest sequence number) message, and assign a unique Message ID to each of the subsequent messages with a duplicate of that Message ID.
二つ以上のメッセージが同じメッセージIDを持っている場合は、最初の（最も低いシーケンス番号）メッセージにそのメッセージIDを使用し、そのメッセージIDの重複を持つ後続のメッセージのそれぞれに固有のメッセージIDを割り当てます。
If no message can be found with a given Message ID, create a dummy message with this ID. Use this dummy message for all subsequent references to this ID.
何のメッセージが与えられたメッセージIDを見つけることができなかった場合は、このIDを持つダミーのメッセージを作成します。このIDへの後続のすべての参照のために、このダミーのメッセージを使用してください。
If a message already has a parent, don't change the existing link. This is done because the References header line may have been truncated by a Mail User Agent (MUA). As a result, there is no guarantee that the messages corresponding to adjacent Message IDs in the References header line are parent and child.
メッセージは、すでに親を持っている場合は、既存のリンクを変更しないでください。参照ヘッダー行がメールユーザエージェント（MUA）によって切り捨てされている可能性があるため、これが行われます。その結果、参照ヘッダーラインに隣接するメッセージIDに対応するメッセージは、親と子であるという保証はありません。
Do not create a parent/child link if creating that link would introduce a loop. For example, before making message A the parent of B, make sure that A is not a descendent of B.
そのリンクを作成すると、ループを導入する場合は、親/子リンクを作成しないでください。例えば、メッセージA Bの親行う前に、AがBの子孫ではないことを確認してください
Note: Message ID comparisons are case-sensitive.
注意：メッセージIDの比較は大文字と小文字が区別されます。
(B) Create a parent/child link between the last reference (or NIL if there are no references) and the current message. If the current message already has a parent, it is probably the result of a truncated References header line, so break the current parent/child link before creating the new correct one. As in step 1.A, do not create the parent/child link if creating that link would introduce a loop. Note that if this message has no references, it will now have no parent.
（B）（参照がない場合やNIL）最後の参照間の親/子リンクを作成し、現在のメッセージ。現在のメッセージがすでに親を持っている場合、それはおそらく切り捨て参照ヘッダー行の結果であるので、新しい正しいものを作成する前に、現在の親/子リンクを破ります。そのリンクを作成すると、ループを導入する場合にはステップ1.Aのように、親/子リンクを作成しないでください。このメッセージは何の言及がない場合、それは今は親を持たないことに注意してください。
Note: The parent/child links created in steps 1.A
and 1.B MUST be kept consistent with one another at
ALL times.
(2) Gather together all of the messages that have no parents and make them all children (siblings of one another) of a dummy parent (the "root"). These messages constitute the first (head) message of the threads created thus far.
（2）一緒に何の親を持たないすべてのメッセージを収集し、それらすべての子どもダミーの親の（「ルート」）（互いの兄弟）を作ります。これらのメッセージは、これまでに作成されたスレッドの最初（先頭）メッセージを構成しています。
(3) Prune dummy messages from the thread tree. Traverse each thread under the root, and for each message:
（3）スレッドツリーからダミーのメッセージを剪定。ルートの下に、各スレッドを横断し、各メッセージについて：
If it is a dummy message with NO children, delete it.
それはNO子供を持つダミーのメッセージである場合は、それを削除します。
If it is a dummy message with children, delete it, but promote its children to the current level. In other words, splice them in with the dummy's siblings.
それは子供を持つダミーのメッセージである場合は、それを削除しますが、現在のレベルにその子を推進しています。言い換えれば、ダミーの兄弟でそれらをつなぎ合わせ。
Do not promote the children if doing so would make them children of the root, unless there is only one child.
唯一の子が存在しない限り、そうすることが、彼らに根の子供を作るならば、子供を宣伝することはできません。
(4) Sort the messages under the root (top-level siblings only) by sent date as described in section 2.2. In the case of a dummy message, sort its children by sent date and then use the first child for the top-level sort.
セクション2.2で説明したように（4）送信日付ルート（最上位レベルの兄弟のみ）下のメッセージをソート。ダミーメッセージの場合は、送信された期日までにその子を並べ替えた後、トップレベルのソートのための第1子を使用しています。
(5) Gather together messages under the root that have the same base subject text.
（5）同一のベース対象テキストを持っているルートの下に一緒にメッセージを収集します。
(A) Create a table for associating base subjects with
messages, called the subject table.
(B) Populate the subject table with one message per each base subject. For each child of the root:
（B）各基地被験者ごとにメッセージを有する対象テーブルを移入。ルートのそれぞれの子のために：
(i) Find the subject of this thread, by using the
base subject from either the current message or
its first child if the current message is a
dummy. This is the thread subject.
(ii) If the thread subject is empty, skip this message.
スレッド対象が空である場合（ii）は、このメッセージをスキップします。
(iii) Look up the message associated with the thread subject in the subject table.
（III）対象テーブルにおけるスレッド対象に関連付けられたメッセージを検索します。
(iv) If there is no message in the subject table with the thread subject, add the current message and the thread subject to the subject table.
スレッド被写体と被写体台にメッセージがない場合は（IV）、サブジェクトテーブルに現在のメッセージスレッドの件名を追加します。
Otherwise, if the message in the subject table is
not a dummy, AND either of the following criteria
are true:
The current message is a dummy, OR
現在のメッセージはダミーで、OR
The message in the subject table is a reply or forward and the current message is not.
サブジェクトテーブル内のメッセージが返信または転送され、現在のメッセージではありません。
then replace the message in the subject table with the current message.
その後、現在のメッセージに件名テーブルでメッセージを交換してください。
(C) Merge threads with the same thread subject. For each child of the root:
（C）同じスレッド対象とスレッドをマージします。ルートのそれぞれの子のために：
(i) Find the message's thread subject as in step
5.B.i above.
(ii) If the thread subject is empty, skip this message.
スレッド対象が空である場合（ii）は、このメッセージをスキップします。
(iii) Lookup the message associated with this thread subject in the subject table.
（III）対象テーブルにおけるこのスレッド対象に関連付けられたメッセージをルックアップ。
(iv) If the message in the subject table is the current message, skip this message.
（IV）サブジェクトテーブル内のメッセージが現在のメッセージである場合、このメッセージをスキップします。
Otherwise, merge the current message with the one in the subject table using the following rules:
そうでない場合は、次のルールを使用して、サブジェクトテーブル内の1つで現在のメッセージをマージします。
If both messages are dummies, append the current
message's children to the children of the message
in the subject table (the children of both messages
become siblings), and then delete the current
message.
If the message in the subject table is a dummy and the current message is not, make the current message a child of the message in the subject table (a sibling of its children).
対象テーブル内のメッセージはダミーであり、現在のメッセージがない場合は、現在のメッセージ件名テーブルのメッセージ（その子の兄弟）の子にします。
If the current message is a reply or forward and the message in the subject table is not, make the current message a child of the message in the subject table (a sibling of its children).
現在のメッセージが対象テーブルの返信または転送、メッセージがされていない場合には、現在のメッセージ件名テーブルのメッセージ（その子の兄弟）の子にします。
Otherwise, create a new dummy message and make both the current message and the message in the subject table children of the dummy. Then replace the message in the subject table with the dummy message.
そうでない場合は、新しいダミーのメッセージを作成して、現在のメッセージとダミーの対象テーブルの子どもたちにメッセージの両方を行います。そして、ダミーのメッセージで、対象表でメッセージを交換してください。
Note: Subject comparisons are case-insensitive, as described under "Internationalization Considerations".
注：「国際化の考慮事項」に記載されているようにサブジェクト比較は、大文字と小文字を区別しません。
(6) Traverse the messages under the root and sort each set of siblings by sent date as described in section 2.2. Traverse the messages in such a way that the "youngest" set of siblings are sorted first, and the "oldest" set of siblings are sorted last (grandchildren are sorted before children, etc). In the case of a dummy message (which can only occur with top-level siblings), use its first child for sorting.
（6）根の下にメッセージを横断し、セクション2.2に記載したように送信された日付によって兄弟の各セットを並べ替えます。 「最年少は、」兄弟のセットが最初にソートされているような方法で、メッセージ、およびトラバース「最古」は兄弟のセットが（孫など、子供たちの前にソートされている）最後にソートされています。 （唯一のトップレベル兄弟で発生する可能性がある）ダミーメッセージの場合には、ソートにその最初の子を使用します。
Example: C: A283 THREAD ORDEREDSUBJECT UTF-8 SINCE 5-MAR-2000 S: * THREAD (166)(167)(168)(169)(172)(170)(171) (173)(174 (175)(176)(178)(181)(180))(179)(177 (183)(182)(188)(184)(185)(186)(187)(189))(190) (191)(192)(193)(194 195)(196 (197)(198))(199) (200 202)(201)(203)(204)(205)(206 207)(208) S: A283 OK THREAD completed C: A284 THREAD ORDEREDSUBJECT US-ASCII TEXT "gewp" S: * THREAD S: A284 OK THREAD completed C: A285 THREAD REFERENCES UTF-8 SINCE 5-MAR-2000 S: * THREAD (166)(167)(168)(169)(172)((170)(179)) (171)(173)((174)(175)(176)(178)(181)(180)) ((177)(183)(182)(188 (184)(189))(185 186)(187)) (190)(191)(192)(193)((194)(195 196))(197 198) (199)(200 202)(201)(203)(204)(205 206 207)(208) S: A285 OK THREAD completed
例：C：A283スレッドORDEREDSUBJECT UTF-8 5-MAR-2000のS SINCE：*ねじ山（166）（167）（168）（169）（172）（170）（171）（173）（174（175）（ 176）（178）（181）（180））（179）（177（183）（182）（188）（184）（185）（186）（187）（189））（190）（191）（192 ）（193）（194 195）（196（197）（198））（199）（200 202）（201）（203）（204）（205）（206 207）（208）S：A283 OKスレッドがC完了します：A284スレッドORDEREDSUBJECT US-ASCIIのTEXT "gewp" S：*スレッドS：A284 OK THREAD完了C：A285スレッドREFERENCES UTF-8 5-MAR-2000のS SINCE：* THREAD（166）（167）（168）（169 ）（172）（（170）（179））（171）（173）（（174）（175）（176）（178）（181）（180））（（177）（183）（182）（188 （184）（189））（185 186）（187））（190）（191）（192）（193）（（194）（195 196））（197 198）（199）（200 202）（201） （203）（204）（205 206 207）（208）S：終了A285 OK THREAD
Note: The line breaks in the first and third server
responses are for editorial clarity and do not appear in
real THREAD responses.
These responses are extensions to the [IMAP] base protocol.
これらの応答は、[IMAP]ベースプロトコルの拡張機能です。
The section headings of these responses are intended to correspond with where they would be located in the main document.
これらの応答のセクションの見出しは、それらがメインドキュメント内に配置される場所に対応するように意図されています。
BASE.7.2.SORT. SORT Response
BASE.7.2.SORT。 SORTレスポンス
Data: zero or more numbers
データ：ゼロ以上の数字
The SORT response occurs as a result of a SORT or UID SORT command. The number(s) refer to those messages that match the search criteria. For SORT, these are message sequence numbers; for UID SORT, these are unique identifiers. Each number is delimited by a space.
SORT応答は、SORTまたはUID SORTコマンドの結果として生じます。番号（複数可）、検索条件に一致するメッセージを参照してください。 SORTの場合、これらは、メッセージシーケンス番号です。 UID SORTのために、これらのユニークな識別子です。各数値はスペースで区切られています。
Example: S: * SORT 2 3 6
例：S：* SORT 2 3 6
BASE.7.2.THREAD. THREAD Response
BASE.7.2.THREAD。 THREAD応答
Data: zero or more threads
データ：ゼロ以上のスレッド
The THREAD response occurs as a result of a THREAD or UID THREAD command. It contains zero or more threads. A thread consists of a parenthesized list of thread members.
THREAD応答は、スレッドまたはUID THREADコマンドの結果として生じます。それは、ゼロ以上のスレッドが含まれています。スレッドはスレッドのメンバーの括弧で囲まれたリストで構成されます。
Thread members consist of zero or more message numbers, delimited by spaces, indicating successive parent and child. This continues until the thread splits into multiple sub-threads, at which point, the thread nests into multiple sub-threads with the first member of each sub-thread being siblings at this level. There is no limit to the nesting of threads.
スレッド部材は、連続親子を示し、スペースで区切られたゼロ個以上のメッセージ番号、から成ります。スレッドがこのレベルで、各サブスレッドである兄弟の第一部材と複数のサブスレッドに、その時点で、複数のサブスレッドにスレッド巣を分割するまで続きます。スレッドの入れ子に制限はありません。
The messages numbers refer to those messages that match the search criteria. For THREAD, these are message sequence numbers; for UID THREAD, these are unique identifiers.
メッセージ番号は、検索条件に一致するメッセージを参照してください。 THREADに関しては、これらは、メッセージシーケンス番号です。 UID THREADのために、これらは一意の識別子です。
Example: S: * THREAD (2)(3 6 (4 23)(44 7 96))
例：S：*ねじ山（2）（3 6（4 23）（44 7 96））
The first thread consists only of message 2. The second thread consists of the messages 3 (parent) and 6 (child), after which it splits into two sub-threads; the first of which contains messages 4 (child of 6, sibling of 44) and 23 (child of 4), and the second of which contains messages 44 (child of 6, sibling of 4), 7 (child of 44), and 96 (child of 7). Since some later messages are parents of earlier messages, the messages were probably moved from some other mailbox at different times.
最初のスレッドは、2つのサブスレッドに分割された後にメッセージ3（親）と6（子）、から成る第二のスレッド2.メッセージのみから成ります。 、メッセージ4（6の子、44の兄弟）および23（4の子）、およびメッセージ44（6の子、4の兄弟）が含まれた第2を含む最初の7（44の子）、および96（7の子）。その後のあるメッセージは、以前のメッセージの親なので、メッセージはおそらく異なる時間にいくつかの他のメールボックスから移動されました。
-- 2
ーー ２
-- 3 \-- 6 |-- 4 | \-- 23 | \-- 44 \-- 7 \-- 96
ーー ３ ￥ーー ６ ｜ーー ４ ｜ ￥ーー ２３ ｜ ￥ーー ４４ ￥ーー ７ ￥ーー ９６
Example: S: * THREAD ((3)(5))
例：S：*ねじ山（（3）（5））
In this example, 3 and 5 are siblings of a parent that does not match the search criteria (and/or does not exist in the mailbox); however they are members of the same thread.
この例では、図3及び図5は、検索条件に一致しない（および/またはメールボックスに存在しない）、親の兄弟です。しかし彼らは、同じスレッドのメンバーです。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. It also uses [ABNF] rules defined in [IMAP].
以下の構文仕様は、[ABNF]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。また、[IMAP]で定義された[ABNF]ルールを使用しています。
sort = ["UID" SP] "SORT" SP sort-criteria SP search-criteria
ソート= [ "UID" SP] "SORT" SPソート基準のSPの検索条件
sort-criteria = "(" sort-criterion *(SP sort-criterion) ")"
ソート基準=「（」ソート基準*（SPソート基準）「）」
sort-criterion = ["REVERSE" SP] sort-key
ソート基準= [「REVERSE」SP]ソート・キー
sort-key = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" / "SUBJECT" / "TO"
ソート・キー= "到着" / "CC" / "DATE" / "FROM" / "SIZE" / "SUBJECT" / "TO"
thread = ["UID" SP] "THREAD" SP thread-alg SP search-criteria
スレッド= [ "UID" SP] "THREAD" SPスレッド-ALG SPの検索条件
thread-alg = "ORDEREDSUBJECT" / "REFERENCES" / thread-alg-ext
スレッド-ALG = "ORDEREDSUBJECT" / "関連情報" /スレッド-ALG-EXT
thread-alg-ext = atom ; New algorithms MUST be registered with IANA
スレッド-ALG-EXT =原子;新しいアルゴリズムは、IANAに登録しなければなりません
search-criteria = charset 1*(SP search-key)
検索条件=文字セット1 *（SP-検索キー）
charset = atom / quoted ; CHARSET values MUST be registered with IANA
文字セット=原子/引用されました。 CHARSETの値は、IANAに登録しなければなりません
sort-data = "SORT" *(SP nz-number)
ソート・データ= "SORT" *（SP NZ-数）
thread-data = "THREAD" [SP 1*thread-list] thread-list = "(" (thread-members / thread-nested) ")"
スレッドデータ= "THREAD" [SP 1 *スレッドリスト]スレッドリスト= "（"（スレッドメンバー/スレッドネストされました） "）"
thread-members = nz-number *(SP nz-number) [SP thread-nested]
スレッドメンバー= NZ-数*（SP NZ-数）[SPスレッドネスト]
thread-nested = 2*thread-list
スレッドネストされた= 2 *スレッド一覧
The following syntax describes base subject extraction rules (2)-(6):
次の構文は、ベース被写体抽出ルールを記述し、（2） - （6）：
subject = *subj-leader [subj-middle] *subj-trailer
対象= * SUBJ-リーダー[SUBJ-ミドル] * SUBJトレーラー
subj-refwd = ("re" / ("fw" ["d"])) *WSP [subj-blob] ":"
SUBJ-refwd =（ "再" /（ "FW" [ "D"]））* WSP [SUBJ-BLOB] "："
subj-blob = "[" *BLOBCHAR "]" *WSP
SUBJ-ブロブ= "[" * BLOBCHAR "]" * WSP
subj-fwd = subj-fwd-hdr subject subj-fwd-trl
SUBJ-FWD = SUBJ-FWD-HDR対象SUBJ-FWD-TRL
subj-fwd-hdr = "[fwd:"
SUBJ-FWD-HDR = "[FWD："
subj-fwd-trl = "]"
SUBJ-FWD-TRL = "]"
subj-leader = (*subj-blob subj-refwd) / WSP
SUBJ-リーダー=（* SUBJ-ブロブSUBJ-refwd）/ WSP
subj-middle = *subj-blob (subj-base / subj-fwd) ; last subj-blob is subj-base if subj-base would ; otherwise be empty
SUBJ中間= * SUBJ-BLOB（SUBJベース/ SUBJ-FWD）。 SUBJ-ベースが希望の場合、最後のsubj-ブロブはSUBJベースです。それ以外の場合は空であります
subj-trailer = "(fwd)" / WSP
SUBJ-トレーラー= "（FWD）" / WSP
subj-base = NONWSP *(*WSP NONWSP) ; can be a subj-blob
SUBJベース= NONWSP *（* WSP NONWSP）。 SUBJ-ブロブすることができ
BLOBCHAR = %x01-5a / %x5c / %x5e-ff ; any CHAR8 except '[' and ']'. ; SHOULD comply with [UTF-8]
BLOBCHAR =％x01-5a /％x5c /％x5e-FF。 '[' と ']' を除く任意のCHAR8。 ; [UTF-8]に従うべきで
NONWSP = %x01-08 / %x0a-1f / %x21-ff ; any CHAR8 other than WSP. ; SHOULD comply with [UTF-8]
NONWSP =％x01-08 /％X0A-1F /％X21-FF; WSP以外のCHAR8。 ; [UTF-8]に従うべきで
The SORT and THREAD extensions do not raise any security considerations that are not present in the base [IMAP] protocol, and these issues are discussed in [IMAP]. Nevertheless, it is important to remember that [IMAP] protocol transactions, including message data, are sent in the clear over the network unless protection from snooping is negotiated, either by the use of STARTTLS, privacy protection in AUTHENTICATE, or some other protection mechanism.
SORTとTHREAD拡張は、ベース[IMAP]プロトコルに存在しない任意のセキュリティ上の考慮事項は発生しません、これらの問題は、[IMAP]で議論されています。それにもかかわらず、スヌーピングからの保護が交渉されていない限り、[IMAP]メッセージデータを含むプロトコルトランザクションは、いずれかのSTARTTLS、AUTHENTICATEにおけるプライバシー保護の使用、または他の保護メカニズムによって、ネットワーク上で平文で送信されていることを覚えておくことが重要です。
Although not a security consideration, it is important to recognize that sorting by REFERENCES can lead to misleading threading trees. For example, a message with false References: header data will cause a thread to be incorporated into another thread.
ないセキュリティの考慮が、REFERENCESによってソートするスレッドの木を誤解につながることを認識することが重要です。例えば、偽参照してメッセージ：ヘッダデータは、スレッドが別のスレッドに組み込まれることになります。
The process of extracting the base subject may lead to incorrect collation if the extracted data was significant text as opposed to a subject artifact.
抽出されたデータは、対象アーティファクトとは対照的に、有意なテキストであった場合、ベース被写体を抽出する処理は、誤った照合をもたらし得ます。
As stated in the introduction, the rules of I18NLEVEL=1 as described in [IMAP-I18N] MUST be followed; that is, the SORT and THREAD extensions MUST collate strings according to the i;unicode-casemap collation described in [UNICASEMAP]. Servers SHOULD also advertise the I18NLEVEL=1 extension. Alternatively, a server MAY implement I18NLEVEL=2 (or higher) and comply with the rules of that level.
冒頭で述べたように、[IMAP-I18N]に記載されているようにI18NLEVEL = 1の規則に従わなければなりません。 【UNICASEMAP]に記載ユニコードCASEMAP照合、すなわち、SORTとTHREAD拡張がIに係る文字列を照合しなければなりません。サーバはまた、I18NLEVEL = 1拡張子を宣伝すべきです。代替的に、サーバはI18NLEVEL = 2（またはそれ以上）を実装し、そのレベルのルールを遵守するかもしれません。
As discussed in [IMAP-I18N] section 4.5, all server implementations should eventually be updated to support the [IMAP-I18N] I18NLEVEL=2 extension.
[IMAP-I18N]セクション4.5で議論するように、すべてのサーバーの実装は、最終的に[IMAP-I18N] I18NLEVEL = 2拡張をサポートするように更新されるべきです。
Translations of the "re" or "fw"/"fwd" tokens are not specified for removal in the base subject extraction process. An attempt to add such translated tokens would result in a geometrically complex, and ultimately unimplementable, task.
「再」又は「FW」/「FWD」トークンは、ベース被写体抽出処理で除去するために指定されていないの翻訳。このように翻訳トークンを追加しようとする試みは、幾何学的に複雑で、そして最終的にunimplementable、タスクにつながります。
Instead, note that [RFC2822] section 3.6.5 recommends that "re:" (from the Latin "res", meaning "in the matter of") be used to identify a reply. Although it is evident that, from the multiple forms of token to identify a forwarded message, there is considerable variation found in the wild, the variations are (still) manageable. Consequently, it is suggested that "re:" and one of the variations of the tokens for a forward supported by the base subject extraction rules be adopted for Internet mail messages, since doing so makes it a simple display-time task to localize the token language for the user.
（「の問題で」意味、ラテン語「RES」から）返事を識別するために使用される：「再」の代わりに、[RFC2822]セクション3.6.5はそれを推奨していることに注意してください。それは転送されたメッセージを識別するためのトークンの複数の形態から、野生で発見かなりのばらつきがあることが明らかであるが、バリエーションが（依然として）管理可能です。ベース被写体抽出規則でサポートされている前方のトークンのバリエーションの1がそうするので、インターネットメールメッセージのために採用され、それは、単純な表示時間のタスクはトークンをローカライズすることができます：したがって、「再」ことが示唆されましたユーザーのための言語。
[IMAP] capabilities are registered by publishing a standards track or IESG-approved experimental RFC. This document constitutes registration of the SORT and THREAD capabilities in the [IMAP] capabilities registry.
[IMAP]機能は、標準トラックやIESGが承認した実験的RFCを公開することにより、登録されています。この文書では、[IMAP]能力レジストリ内SORTとTHREAD能力の登録を構成しています。
This document creates a new [IMAP] threading algorithms registry, which registers threading algorithms by publishing a standards track or IESG-approved experimental RFC. This document constitutes registration of the ORDEREDSUBJECT and REFERENCES algorithms in that registry.
この文書では、基準トラックやIESGが承認した実験的RFCを公開することにより、スレッドのアルゴリズムを登録し、新しい[IMAP]スレッドアルゴリズムのレジストリを作成します。この文書は、そのレジストリにORDEREDSUBJECTとREFERENCESアルゴリズムの登録を構成しています。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、エド、およびP. Overell、。。
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[CHARSET]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IMAP-I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[IMAP-I18N]ニューマン、C.、Gulbrandsenの、A.、およびA.メルニコフ、 "インターネットメッセージアクセスプロトコル国際化"、RFC 5255、2008年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[UNICASEMAP] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
[UNICASEMAP]クリスピン、M.、 "I;ユニコード-CASEMAP - シンプルなUnicode照合アルゴリズム"、RFC 5051、2007年10月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[IMAP-MODELS] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.
[IMAP-MODELS]クリスピン、M.、 "IMAP4に分散電子メールモデル"、RFC 1733、1994年12月。
[THREADING] Zawinski, J. "Message Threading", http://www.jwz.org/doc/threading.html, 1997-2002.
Zawinski、J. "メッセージスレッド"、http://www.jwz.org/doc/threading.html、1997-2002を[スレッド]。
Authors' Addresses
著者のアドレス
Mark R. Crispin Panda Programming 6158 NE Lariat Loop Bainbridge Island, WA 98110-2098
マーク・R.クリスピンパンダプログラミング6158 NEラリアットループベインブリッジ島、ワシントン州98110から2098
Phone: +1 (206) 842-2385 EMail: IMAP+SORT+THREAD@Lingling.Panda.COM
電話：+1（206）842-2385 Eメール：IMAP+SORT+THREAD@Lingling.Panda.COM
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213
ケネス・マーチソンカーネギーメロン大学5000フォーブス・アベニューCyertホール285ピッツバーグ、PA 15213
Phone: +1 (412) 268-2638 EMail: murch@andrew.cmu.edu
電話：+1（412）268-2638 Eメール：murch@andrew.cmu.edu
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に情報を記述してください。