[要約] RFC 5256は、IMAPプロトコルのSORTおよびTHREAD拡張機能に関する仕様です。このRFCの目的は、メールボックス内のメッセージのソートとスレッド化を効率的に行うための方法を提供することです。
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]プロトコルへのソートとスレッドの拡張機能は、クライアントが必要なデータをダウンロードすることなく、メッセージのサーバーベースの並べ替えとスレッドの手段を提供します。これは、[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.
ベースレベルのソート拡張機能をサポートするサーバーは、「ソート」から始まる機能名でこれを示します。ソート拡張機能への将来の上向きの互換性のある拡張はすべて「ソート」から始まり、このベースレベルのサポートを示します。
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の要件に従って、ソートおよび/またはスレッド拡張機能を実装するサーバーは、I18NLEVEL = 1の要件に従って文字列を照合する必要があり、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.
ディスカッション：数年前の[IMAP-I18N]のソートとスレッドの拡張機能。この書き込みの時点で、ソートとスレッドのすべての既知のサーバー実装は、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 Mail and News」バージョン2.0から3.0で記述および使用されている[スレッド]アルゴリズムに基づいています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されていると解釈されます。
The word "can" (not "may") is used to refer to a possible circumstance or situation, as opposed to an optional facility of the protocol.
「can」（「not 'not」）という言葉は、プロトコルのオプションの施設とは対照的に、考えられる状況または状況を指すために使用されます。
"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エンコードワードを変換します。すべてのタブと継続をスペースに変換します。すべての複数のスペースを単一のスペースに変換します。
(2) Remove all trailing text of the subject that matches the subj-trailer ABNF; repeat until no more matches are possible.
(2) Subj-Trailer ABNFに一致する主題のすべての後続のテキストを削除します。これ以上の一致が不可能になるまで繰り返します。
(3) Remove all prefix text of the subject that matches the subj-leader ABNF.
(3) subj-leader 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.
(4) Subj-Blob ABNFに一致する主題のプレフィックステキストがある場合、そのプレフィックスを削除すると、空のサブジベースが残ります。プレフィックステキストを削除します。
(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).
注：ステップ（2）がステップ（6）まで延期することは可能ですが、これにはステップ（4）でサブJ-Trailerをチェックする必要があります。
(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).
(6) 結果のテキストがsubj-fwd-hdr abnfで始まり、subj-fwd-trl abnfで終了する場合、subj-fwd-hdrとsubj-fwd-trlを削除し、ステップ（2）から繰り返します。
(7) The resulting text is the "base subject" used in the SORT.
(7) 結果のテキストは、このソートで使用される「基本科目」です。
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日16:01:33 -0800」は、UTCの日付と時刻の「2001年1月1日00:01:33 0000」に相当します。
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として扱う必要があります。有効な日付または時刻がない場合、日付と時刻は、可能な限り初期の日付で00: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で説明されている）の日付関連基準とは異なり、時間ではなく日付のみを使用し、タイムゾーンで調整されません。
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.
送信日を決定できない場合（日付：ヘッダーが欠落しているか、解析できない）、そのメッセージの内部デートは送信日として使用されます。
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。ソートコマンド
Arguments: sort program charset specification searching criteria (one or more)
引数：プログラムのcharset仕様検索基準（1つ以上）をソート
Data: untagged responses: SORT
データ：未編成の応答：ソート
Result: OK - sort completed NO - sort error: can't sort that charset or criteria BAD - command unknown or arguments invalid
結果：ok-並べ替え完了しない - ソートエラー：そのcharsetまたはcriteria bad -command nowndまたは引数の無効なコマンドをソートできない
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.
ソートコマンドは、結果のセマンティクスをソートすることで、検索のバリアントです。検索基準の引数の前には、ソート基準の括弧付きリストと検索チャーセットの2つの引数があります。
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引数は必須であり（検索とは異なり）、検索基準に表示される文字列の[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ソートコマンドもあります。メッセージシーケンス番号とUIDに個別の検索基準があることに注意してください。したがって、UIDソートの引数は、ソートと同じと解釈されます。これは、UIDコピー、UIDフェッチ、または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つ以上のソート基準に従ってソートして、一致するメッセージを整理されていないソート応答で返します。
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".
ソート基準に従って2つ以上のメッセージが正確に一致する場合、これらのメッセージはメールボックスに表示される順序に従ってソートされます。言い換えれば、「シーケンス番号」の暗黙のソート基準があります。
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.
複数のソート基準が指定されている場合、結果は、基準が表示される優先順序でソートされます。たとえば、（件名の日付）は、基本件名テキストで順番にメッセージを並べ替えます。また、同じ基本件名テキストを持つメッセージの場合、送信された日付までに並べ替えます。
Untagged EXPUNGE responses are not permitted while the server is responding to a SORT command, but are permitted during a UID SORT command.
サーバーがソートコマンドに応答している間は、未編成の抹消応答は許可されていませんが、UIDソートコマンド中に許可されます。
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.
メッセージの内部日付と時刻到着。これは、内部日付のみを使用する検索中のオン基準とは異なります。
CC [IMAP] addr-mailbox of the first "cc" address.
CC [IMAP]最初の「CC」アドレスのAddr-Mailbox。
DATE Sent date and time, as described in section 2.2.
セクション2.2で説明されているように、日付と時刻が送られました。
FROM [IMAP] addr-mailbox of the first "From" address.
[IMAP]から、最初の「From」アドレスのAddr-Mailboxから。
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.
逆に続いて別のソート基準が続き、その基準の効果がありますが、逆（下降）順序です。注：逆方向は単一の基準のみを逆転させ、他のすべての基準が同一である場合、暗黙の「シーケンス番号」ソート基準に影響しません。したがって、一種の逆の被験者は、サブジェクトソートの逆の順序と同じではありません。これは、追加の基準を使用することで回避できます。たとえば、サブジェクトの日付と逆被験者の逆日。ただし、一般に、クライアントが新しいソートを発行するのではなく、クライアントの結果を逆転させる方が優れています（クライアントが「逆の現在の順序付け」コマンドを持っている場合）。
SIZE Size of the message in octets.
オクテットのメッセージのサイズサイズ。
SUBJECT Base subject text.
サブジェクトベースの主題テキスト。
TO [IMAP] addr-mailbox of the first "To" address.
[IMAP]への最初の "to"アドレスのaddr-mailboxへ。
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
BASE.6.4.THREAD. THREAD Command
base.6.4.thread。スレッドコマンド
Arguments: threading algorithm charset specification searching criteria (one or more)
引数：スレッドアルゴリズムのcharset仕様検索基準（1つ以上）
Data: untagged responses: THREAD
データ：タグ付き応答：スレッド
Result: OK - thread completed NO - thread error: can't thread that charset or criteria BAD - command unknown or arguments invalid
結果：ok-スレッド完了しない - スレッドエラー：そのcharsetまたは基準が悪いスレッド - コマンド不明または引数が無効です
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.
スレッドコマンドは、結果のスレッドセマンティクスを使用した検索のバリアントです。スレッドには、検索基準の引数の前に2つの引数があります：スレッドアルゴリズムと検索チャーセット。
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引数は必須であり（検索とは異なり）、検索基準に表示される文字列の[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スレッドコマンドもあります。メッセージシーケンス番号とUIDに個別の検索基準があることに注意してください。したがって、UIDスレッドに対する引数は、スレッドと同じと解釈されます。これは、UIDコピー、UIDフェッチ、または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引数を使用して、指定された検索基準と一致するメッセージのメールボックスを検索します。次に、指定されたスレッドアルゴリズムに従ってスレッドにされた、1つのマッチングメッセージをタグ付けされていないスレッド応答で返します。
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.
サーバーがスレッドコマンドに応答している間は、ogedされていない除去応答は許可されていませんが、UIDスレッドコマンド中に許可されます。
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.
OrdedSubjectスレッドアルゴリズムは、「貧しい人間のスレッド」とも呼ばれます。検索されたメッセージは、ベースの件名によってソートされ、次に送信日によってソートされます。次に、メッセージは別々のスレッドに分割され、各スレッドには同じベースサブジェクトテキストのメッセージが含まれています。最後に、スレッドはスレッド内の最初のメッセージの送信日によってソートされます。
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.
順序付けされたサブジェクトスレッドの上位レベルまたは「ルート」には、すべてのスレッドの最初のメッセージが含まれています。ルート内のすべてのメッセージはお互いの兄弟です。スレッドの2番目のメッセージは最初のメッセージの子であり、スレッドの後続のメッセージは2番目のメッセージの兄弟であり、したがって、ルートのメッセージの子供です。したがって、順番に孫のスレッドに孫はいません。
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.
子どもたちは、子孫の順序付けには子孫がいません。クライアントの実装は、サーバーの応答で子供の子孫をその子供の兄弟として扱う必要があります。
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を表現する複数の方法が得られます。参照スレッディングアルゴリズムの実装は、引用の違いにより誤った非マッチを回避するために、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 <01kf8jceocbs@xxx.yy.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が含まれていない場合、唯一の参照としてIn Reply-to Header行で見つかった最初の（もしあれば）有効なメッセージ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).
メッセージにヘッダーからヘッダーへのラインが含まれていない場合、または繰り返しのヘッダー線に有効なメッセージ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.
メッセージは、元の科目に適用された基本被写体抽出ルールが次のいずれかを削除する場合、返信またはフォワードと見なされます。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.
参照アルゴリズムは、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:
（a）メッセージの参照でメッセージIDを使用して、対応するメッセージ（メッセージ-IDヘッダー行には指定された参照メッセージIDが含まれているもの）を親/子としてリンクします。最初の参照を2番目の親（および2番目の子）、2番目の親は3番目の親（および2番目の子）などを参照します。次のルールは、これらのリンクの作成を支配します。
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.
メッセージにメッセージ-IDヘッダー行が含まれていない場合、またはメッセージIDヘッダー行に有効なメッセージIDが含まれていない場合は、このメッセージに一意のメッセージIDを割り当てます。
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.
2つ以上のメッセージに同じメッセージ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でダミーメッセージを作成します。このDummyメッセージを使用して、この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.
そのリンクを作成するとループが導入される場合、親/子リンクを作成しないでください。たとえば、メッセージを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.
注：手順1.Aおよび1.Bで作成された親/子のリンクは、常に互いに一貫性を保つ必要があります。
(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.
子供がいないダミーメッセージの場合は、削除してください。
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.
子供が1人しかいない限り、子供たちを根の子供にするなら、子供たちを宣伝しないでください。
(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.
(4) セクション2.2で説明されているように、送信された日付でルート（トップレベルの兄弟のみ）の下のメッセージを並べ替えます。ダミーメッセージの場合、送信日で子供を並べ替えてから、トップレベルのソートに最初の子供を使用します。
(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.
（a）件名テーブルと呼ばれるメッセージに基本被写体を関連付けるためのテーブルを作成します。
(B) Populate the subject table with one message per each base subject. For each child of the root:
（b）各ベースサブジェクトごとに1つのメッセージをサブジェクトテーブルに入力します。ルートの各子供のために：
(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.
(i) 現在のメッセージがダミーである場合、現在のメッセージまたはその最初の子供のいずれかの基本科目を使用して、このスレッドの主題を見つけます。これがスレッドの主題です。
(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
現在のメッセージはダミーです
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.
(i) 上記のステップ5.B.Iのように、メッセージのスレッドの件名を見つけます。
(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:
それ以外の場合は、次のルールを使用して、現在のメッセージを件名テーブルのメッセージとマージします。
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) rootの下でメッセージを横断し、セクション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
Note: The line breaks in the first and third server responses are for editorial clarity and do not appear in real THREAD responses.
注：1番目と3番目のサーバー応答のラインブレークは、編集の明確さのためであり、実際のスレッド応答には表示されません。
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。応答をソートします
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.
ソート応答は、ソートまたはUIDソートコマンドの結果として発生します。番号は、検索条件に一致するメッセージを指します。ソートの場合、これらはメッセージシーケンス番号です。UIDソートの場合、これらは一意の識別子です。各番号はスペースによって区切られています。
Example: S: * SORT 2 3 6
BASE.7.2.THREAD. THREAD Response
base.7.2.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.
スレッド応答は、スレッドまたはUIDスレッドコマンドの結果として発生します。ゼロ以上のスレッドが含まれています。スレッドは、スレッドメンバーの括弧付きリストで構成されています。
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.
メッセージ番号は、検索基準に一致するメッセージを指します。スレッドの場合、これらはメッセージシーケンス番号です。UIDスレッドの場合、これらは一意の識別子です。
Example: S: * THREAD (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のみで構成されています。2番目のスレッドはメッセージ3（親）と6（子）で構成され、その後2つのサブスレッドに分割されます。1つ目には、メッセージ4（6人の子供、44人の兄弟）と23（4人の子供）が含まれ、2番目にはメッセージ44（6人の子供、4人の兄弟）、7（44人の子供）、およびメッセージが含まれています。96（7の子供）。後のメッセージは以前のメッセージの親であるため、メッセージはおそらく異なる時期に他のメールボックスから移動されました。
-- 2
-2
-- 3
\-- 6
|-- 4
| \-- 23
|
\-- 44
\-- 7
\-- 96
Example: S: * THREAD ((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]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。また、[IMAP]で定義されている[ABNF]ルールも使用します。
sort = ["UID" SP] "SORT" SP sort-criteria SP search-criteria
sort-criteria = "(" sort-criterion *(SP sort-criterion) ")"
sort-criterion = ["REVERSE" SP] sort-key
sort-key = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" /
"SUBJECT" / "TO"
thread = ["UID" SP] "THREAD" SP thread-alg SP search-criteria
thread-alg = "ORDEREDSUBJECT" / "REFERENCES" / thread-alg-ext
thread-alg-ext = atom ; New algorithms MUST be registered with IANA
thread-alg-ext = atom;新しいアルゴリズムはIANAに登録する必要があります
search-criteria = charset 1*(SP search-key)
検索基準= charset 1*（sp search-key）
charset = atom / quoted ; CHARSET values MUST be registered with IANA
charset = atom / quoted;charset値はianaに登録する必要があります
sort-data = "SORT" *(SP nz-number)
sort-data = "sort" *（sp nz-number）
thread-data = "THREAD" [SP 1*thread-list]
thread-list = "(" (thread-members / thread-nested) ")"
thread-members = nz-number *(SP nz-number) [SP thread-nested]
スレッドメンバー= nz-number *（sp nz-number）[sp thread-nested]
thread-nested = 2*thread-list
thread-nested = 2*スレッドリスト
The following syntax describes base subject extraction rules (2)-(6):
次の構文は、基本主題抽出ルール（2） - （6）を説明しています。
subject = *subj-leader [subj-middle] *subj-trailer
subj-refwd = ("re" / ("fw" ["d"])) *WSP [subj-blob] ":"
subj-blob = "[" *BLOBCHAR "]" *WSP
subj-fwd = subj-fwd-hdr subject 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-middle = *subj-blob (subj-base / subj-fwd)
; last subj-blob is subj-base if subj-base would
; otherwise be empty
subj-trailer = "(fwd)" / WSP
subj-base = NONWSP *(*WSP NONWSP)
; can be a subj-blob
BLOBCHAR = %x01-5a / %x5c / %x5e-ff
; any CHAR8 except '[' and ']'.
; SHOULD comply with [UTF-8]
NONWSP = %x01-08 / %x0a-1f / %x21-ff
; any CHAR8 other than WSP.
; SHOULD comply with [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.
ソートとスレッドの拡張機能は、ベース[IMAP]プロトコルに存在しないセキュリティ上の考慮事項を提起せず、これらの問題は[IMAP]で説明されています。それにもかかわらず、STARTTLSの使用、認証におけるプライバシー保護、またはその他の保護メカニズムのいずれかによってスヌーピングからの保護が交渉されない限り、メッセージデータを含む[IMAP]プロトコルトランザクションはネットワーク上でクリアに送信されることを覚えておくことが重要です。。
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.
セキュリティの考慮事項ではありませんが、参照による並べ替えが誤解を招くようなスレッドツリーにつながる可能性があることを認識することが重要です。たとえば、誤った参照を含むメッセージ：ヘッダーデータにより、スレッドが別のスレッドに組み込まれます。
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]に記載されているi; unicode-casemap照合に従って、ソートとスレッドの拡張機能を照合する必要があります。サーバーは、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.
「Re」または「FW」/「FWD」トークンの翻訳は、基本被写体抽出プロセスで除去するために指定されていません。このような翻訳されたトークンを追加しようとすると、幾何学的に複雑で、最終的には実現できないタスクが生じます。
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.
代わりに、[RFC2822]セクション3.6.5は、「re：」（「restin "from the" from "in the of"）を使用して返信を識別することを推奨していることに注意してください。転送されたメッセージを識別するための複数の形式のトークンから、野生でかなりのバリエーションが見られることは明らかですが、バリエーションは（まだ）管理可能です。したがって、「Re：」と、ベースサブジェクト抽出ルールによってサポートされる前方のトークンのバリエーションの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]機能レジストリのソートおよびスレッド機能の登録を構成します。
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および参照アルゴリズムの登録を構成します。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[Charset] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、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] Newman、C.、Gulbrandsen、A。、およびA. Melnikov、「インターネットメッセージアクセスプロトコル国際化」、RFC 5255、2008年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P.、ed。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[UNICASEMAP] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
[Unicasemap] Crispin、M。、「i; Unicode -Casemap-単純なユニコード照合アルゴリズム」、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] Crispin、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
Mark R. Crispin Pandaプログラミング6158 NE Lariat Loop Bainbridge Island、WA 98110-2098
Phone: +1 (206) 842-2385
EMail: IMAP+SORT+THREAD@Lingling.Panda.COM
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213
ケネスマーチソンカーネギーメロン大学5000フォーブスアベニューサイエートホール285ピッツバーグ、ペンシルベニア州15213
Phone: +1 (412) 268-2638
EMail: murch@andrew.cmu.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。