RFC5256 日本語訳
5256 Internet Message Access Protocol - SORT and THREAD Extensions. M.Crispin, K. Murchison. June 2008. (Format: TXT=40779 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Crispin
Request for Comments: 5256 Panda Programming
Category: Standards Track K. Murchison
Carnegie Mellon University
June 2008
コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 5256年のパンダプログラミングカテゴリ: 標準化過程K.マーチソンカーネギーメロン大学2008年6月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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クライアントにかなりの性能改良を提供します。
1. Introduction
1. 序論
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拡張子への将来的で、上向きにコンパチブル拡大はすべて、「種類」から始まるでしょう。
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つ以上の能力名が支持された縫うように通るアルゴリズム名が本書では説明されるようにあとに続いた「糸=」から成っていて、THREAD拡張子をサポートするサーバはこれを示します。 これは今後の上向きにコンパチブル拡大に備えます。
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.
I18NLEVEL=1の要件に従ってSORT、そして/または、THREAD拡張子を実行するサーバが[IMAP-I18N]で説明されるようにストリングを照合しなければならなくて、SHOULDはI18NLEVEL=1拡張子を実行して、広告を出します。 あるいはまた、サーバは、I18NLEVEL=2を実行して(より高い)、そのレベルの規則に従うかもしれません。
Crispin & Murchison Standards Track [Page 1] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[1ページ]
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.
歴史的な注意: REFERENCES縫うように通るアルゴリズムは「Netscapeメールとニュース」バージョン2.0〜3.0で書かれていて、使用される[THREADING]アルゴリズムに基づいています。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?
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"(“may"でない)は可能な状況か状況について言及するのに使用されます、プロトコルの任意の施設と対照的に。
"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:」 クライアントとサーバによってそれぞれ送られた線を示してください。
2.1. Base Subject
2.1. 基地の対象
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]に対する対象のコード化された単語のあらゆるRFC2047を変換してください。 すべてのタブと続刊をスペースに変換してください。 すべての複数の空間をシングルスペースに変換してください。
(2) Remove all trailing text of the subject that matches the
subj-trailer ABNF; repeat until no more matches are possible.
(2) 首題トレーラABNFに合っている対象のすべての引きずっているテキストを取り除いてください。 それ以上のマッチが可能にならないまで、繰り返してください。
(3) Remove all prefix text of the subject that matches the subj-
leader ABNF.
(3) 首題リーダーABNFに合っている対象のすべての接頭語テキストを取り除いてください。
Crispin & Murchison Standards Track [Page 2] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[2ページ]
(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) 首題一滴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).
以下に注意してください。 ステップ(6)までステップ(2)を延期するのが可能ですが、これは、首題トレーラがないかどうかステップ(4)でチェックするのを必要とします。
(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) 結果として起こるテキストが首題-fwd-trl ABNFと共に首題-fwd-hdr ABNFと終わりで始まるなら、首題-fwd-hdrと首題-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]で説明されるように)クライアントは、「ベース対象」を決定するのにまさにこのアルゴリズムを使用しなければなりません。 さもなければ、ユーザがそれらが接続されたか外されたモードへ駆け込んでいるかどうか基づく矛盾した結果を得る可能性があります。
2.2. Sent Date
2.2. 送られた期日
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」は「2001年1月1日の00: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.
時間帯が病人と、日付と時間SHOULDであるなら、UTCとして扱われてください。 時間であるなら、病人も、時間はSHOULDです。00:00:00として、扱われてください。 いいえ、有効な期日か時間と、日付と時間SHOULDあれば。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.
送られた期日を測定できないなら(日付:ヘッダーは、なくなるか、または分析できません)、そのメッセージのための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つのメッセージがメールボックス(すなわち、一連番号に従った)の中に現れるオーダーは、順番を決定するのにタイブレークとして使用されます。
Crispin & Murchison Standards Track [Page 3] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[3ページ]
3. Additional Commands
3. 追加コマンド
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
.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か評価基準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コマンドは結果のために意味論を分類する検索の異形です。 探す評価基準議論の前に、2つの議論があります: 種類の評価基準のparenthesizedリスト、および探している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議論は、義務的であり(検索と異なった)、探す評価基準に現れるストリングの[CHARSET]を示します。 米国-ASCIIと[UTF-8]charsetsを実行しなければなりません。 他のすべてのcharsetsが任意です。
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コマンドがあります。 メッセージ通番とUIDsの別々の探す評価基準があることに注意してください。 したがって、UID SORTへの議論はSORTで同じように解釈されます。 これはUID COPY、UID FETCH、またはUID STOREと対照的にUID SEARCHの動きに類似しています。
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つ以上の種類の評価基準に従って分類されたuntagged 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").
ソーティングが昇順であります。 後の数日以前以前の日付の種類。 より小さいサイズは以前、より大きいサイズを分類します。 そして、それらの照合アルゴリズムで確立された値を昇るのに従って、ストリングは分類されます(「国際化問題」を見てください)。
Crispin & Murchison Standards Track [Page 4] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[4ページ]
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.
複数の種類の評価基準が指定されるとき、結果は評価基準が見える優先順で分類されます。 例えば、(SUBJECT DATE)はそれらのベース対象テキストで整然としているメッセージを分類するでしょう。 そして、同じくらいがあるメッセージに関して、対象のテキストを基礎づけてください、そして、それは彼らの送られた期日までに分類されるでしょう。
Untagged EXPUNGE responses are not permitted while the server is
responding to a SORT command, but are permitted during a UID SORT
command.
Untagged 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.
定義された種類の評価基準は以下の通りです。 議論の正確な構文の定義についてFormal Syntax部を参照してください。 特定の評価基準のための関連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 Internal日時。 これは検索におけるON評価基準と異なっています。(検索はまさしく内部の期日を使用します)。
CC
[IMAP] addr-mailbox of the first "cc" address.
最初の「cc」アドレスの[IMAP]addr-メールボックスをCCしてください。
DATE
Sent date and time, as described in section 2.2.
セクション2.2で説明されるようなDATE Sent日時。
FROM
[IMAP] addr-mailbox of the first "From" address.
最初の“From"アドレスのFROM[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 Followedはその評価基準について評価基準を分類して、効果を持っていますが、逆(下る)では、注文してください。 以下に注意してください。 REVERSEだけがただ一つの評価基準を逆にして、他のすべての評価基準が同じであるなら、暗黙の「一連番号」種類の評価基準に影響しません。 その結果、一種のREVERSE SUBJECTはSUBJECT種類を注文する逆と同じではありません。 追加評価基準の使用、例えば、SUBJECT DATE対REVERSE SUBJECT REVERSE DATEはこれを避けることができます。 しかしながら、一般に、それは新しいSORTを発行することの代わりにクライアントで逆に結果を改善する(クライアントが、aが「現在の注文を逆にすること」を持っているなら、より速く、命令してください)ことです。
Crispin & Murchison Standards Track [Page 5] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[5ページ]
SIZE
Size of the message in octets.
八重奏におけるメッセージのSIZE Size。
SUBJECT
Base subject text.
SUBJECT基地の対象テキスト。
TO
[IMAP] addr-mailbox of the first "To" address.
最初の“To"アドレスのTO[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は1994年2月1日S以来の(受けることがある)のUTF-8を分類します: * 882秒間の種類2の84: A282 OK SORTはCを完成しました: A283が(対象の逆の期日)UTF-8を分類する、すべてのS: * 2秒間の種類5 3 4 1: A283 OK SORTはCを完成しました: A284 SORT(SUBJECT)の「メールボックスでない」の米国のASCII TEXTのS: * 種類S: 完成したA284 OK SORT
BASE.6.4.THREAD. THREAD Command
.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か評価基準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.
THREADコマンドは結果のために意味論に糸を通す検索の異形です。 糸には、探す評価基準議論の前に、2つの議論があります: 縫うように通るアルゴリズムと探している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議論は、義務的であり(検索と異なった)、探す評価基準に現れるストリングの[CHARSET]を示します。 米国-ASCIIと[UTF-8]charsetsを実行しなければなりません。 他のすべてのcharsetsが任意です。
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コマンドがあります。 メッセージ通番とUIDsの別々の探す評価基準があることに注意してください。 したがって、UID THREADへの議論はTHREADで同じように解釈されます。 これはUID COPY、UID FETCH、またはUID STOREと対照的にUID SEARCHの動きに類似しています。
Crispin & Murchison Standards Track [Page 6] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[6ページ]
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議論を使用することで与えられた探す評価基準に合っているメッセージのためのメールボックスが最初に探されると命令します。 そして、それは指定された縫うように通るアルゴリズムによると、糸を通されたuntagged THREAD応答における合っているメッセージを返します。
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.
Untagged 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の縫うように通ることにおける子供はdescendentsを持っていません。 クライアント実現SHOULDはその子供の兄弟であるとしてサーバ応答で子供のdescendentsを扱います。
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.
親/子供関係でそれらを分類するのによる捜されたメッセージがどのメッセージに基礎づけたREFERENCES縫うように通るアルゴリズム糸は他のものへの回答です。 2つの方法を使用するのは親/子供関係に建てられます: それの中に含まれた参照を使用することでメッセージの祖先を再建します。 そして、それがそうであるかどうかを見るメッセージのオリジナル(ベースでない)の対象をチェックする、aが答える(前進)、別のメッセージ。
Crispin & Murchison Standards Track [Page 7] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[7ページ]
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.
以下に注意してください。 以下の記述における「Message ID」は[RFC2822]のmsg-イドの正規形を示します。 同じMessage IDを言い表す複数の方法をもたらして、RFC2822の実際のテキストは引用を使用するかもしれません。 REFERENCES縫うように通るアルゴリズムの実現は、引用の違いのため偽の非マッチを避けるためにどんなmsg-イドも正常にしなければなりません。
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-イド<「01KF8JCEOCBS0045PS」@xxx.yyy.com>と msg-id <01KF8JCEOCBS0045PS@xxx.yyy.com 、gt;、同じMessage 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.
メッセージがReferencesヘッダー線を含むなら、参照としてReferencesヘッダー線にMessage 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.
メッセージがReferencesヘッダー線を含んでいないか、またはReferencesヘッダー線が少しの有効なMessage IDも含まないなら中で見つけられた最初(もしあれば)の有効なMessage IDを使用してください、Inが答える、このメッセージの唯一の参照(親)としてのヘッダー線。
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]が複数のMessage IDの入るのを許す、Inが答える、ヘッダー、実際行なわれているところではこの規律は従われていません。 例えば、Inが答える、ヘッダーはMessage IDの後のメッセージアドレスで観察されて、ソフトウェアが違いを決定するように、どんな良い発見的教授法もありません。 しかしながら、これはReferencesヘッダーに関する問題ではありません。
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が答える、ヘッダー線、Inが答える、メッセージには、ヘッダー線は有効なMessage 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.
メッセージが回答であると考えられるか、または前方に、オリジナルの対象に適用された取り出し規則はベース対象であるなら以下のどれかを移します: 首題-refwdか、「(fwd)」首題トレーラか、首題-fwd-hdrと首題-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ステップから成ります。 これらのステップは以下に詳細に概説されています。
Crispin & Murchison Standards Track [Page 8] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[8ページ]
(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) メッセージの参照でMessage IDを使用して、親/子供として対応するメッセージ(Message-IDヘッダー線が与えられた参照Message IDを含むそれら)を一緒に、リンクしてください。 作成、1番目は2番目(そして、1第歳の2番目のa子供)の親に参照をつけて、秒は3(そして、2番目の3番目のa子供)番目などの親です。 以下の規則はこれらのリンクの創造を治めます:
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.
メッセージがMessage-IDヘッダー線を含んでいないか、またはMessage-IDヘッダー線が有効なMessage IDを含まないなら、ユニークなMessage 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つ以上のメッセージに同じMessage IDがあるなら、最初(最も低い一連番号)のメッセージで単にそのMessage IDを使用してください、そして、そのMessage IDの写しでユニークなMessage 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.
与えられたMessage 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.
メッセージに親が既にいるなら、既存のリンクを変えないでください。 Referencesヘッダー線がメール・ユーザー・エージェント(MUA)によって先端を切られたかもしれないので、これをします。 その結果、Referencesヘッダー線における隣接しているMessage 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を作る前に、AがBにおける下降のaでないことを確実にしてください。
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,
(B) 最後の参照(そこであるなら、NILは参照でない)と現在のメッセージとの親/子供リンクを作成してください。 現在のメッセージに親が既にいるなら、それがたぶん端が欠けているReferencesヘッダー線の結果であるので、新しい正しい方を作成する前に、現在の親/子供リンクを壊してください。 ステップ1.Aのように
Crispin & Murchison Standards Track [Page 9] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[9ページ]
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.
そのリンクを作成すると輪が紹介されるなら、親/子供リンクを作成しないでください。 このメッセージに参照が全くないと、それには親が全く現在いないことに注意してください。
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) 糸の対象が空であるなら、このメッセージをスキップしてください。
Crispin & Murchison Standards Track [Page 10] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[10ページ]
(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.
(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).
対象のテーブルのメッセージがダミーであり、現在のメッセージがダミーでないなら、対象のテーブル(子供の兄弟)のメッセージの子供に現在のメッセージを作ってください。
Crispin & Murchison Standards Track [Page 11] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[11ページ]
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は2000秒間の3月5日以来のORDEREDSUBJECT UTF-8に糸を通します: * (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はCを完成しました: A284はORDEREDSUBJECT米国-ASCIIテキスト"gewp"Sに糸を通します: * 糸S: A284 OK THREADはCを完成しました: A285は2000秒間の3月5日以来の参照UTF-8に糸を通します: * (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.
以下に注意してください。 1番目と3番目のサーバ応答におけるラインブレイクは、編集の明快ためにあって、本当のTHREAD応答に現れません。
Crispin & Murchison Standards Track [Page 12] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[12ページ]
4. Additional Responses
4. 追加応答
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
.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.
SORT応答はSORTかUID SORTコマンドの結果、起こります。 数は検索評価基準に合っているそれらのメッセージを示します。 SORTに関しては、これらはメッセージ通番です。 UID SORTに関しては、これらはユニークな識別子です。 各数はスペースによって区切られます。
Example: S: * SORT 2 3 6
例: S: * 種類2 3 6
BASE.7.2.THREAD. THREAD Response
.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.
THREAD応答はTHREADかUID THREADコマンドの結果、起こります。 それがゼロを含んでいるか、または以上は縫うように通ります。 糸は糸のメンバーのparenthesizedリストから成ります。
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.
糸のメンバーはゼロか連続した親子を示す空間によって区切られたより多くのメッセージ番号から成ります。 糸が複数のサブ糸に分かれるまで、これは続きます、どのポイントで、第1代このレベルにおいて兄弟であるそれぞれのサブ糸のメンバーがいる複数のサブ糸への糸の巣。 糸の巣篭もりへの限界が全くありません。
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だけから成ります。 2番目の糸はメッセージ3(親)と6(子供)から成ります。(その時2個のサブ糸に分かれました)後。 それの1番目はメッセージ4(6歳の子供、44歳の兄弟)と23(4歳の子供)を含みます、そして、それの2番目はメッセージ44(6歳の子供、4歳の兄弟)、7(44歳の子供)、および96(7歳の子供)を含んでいます。 以来いくつかの後のメッセージが以前のメッセージの両親である、メッセージはある他のメールボックスといろいろな時間にたぶん動かされました。
Crispin & Murchison Standards Track [Page 13] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[13ページ]
-- 2
-- 2
-- 3
\-- 6
|-- 4
| \-- 23
|
\-- 44
\-- 7
\-- 96
-- 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は検索評価基準(そして/または、メールボックスの中に存在していない)に合っていない親の兄弟です。 しかしながら、彼らは同じ糸のメンバーです。
5. Formal Syntax of SORT and THREAD Commands and Responses
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]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。 また、それは[IMAP]で定義された[ABNF]規則を使用します。
sort = ["UID" SP] "SORT" SP sort-criteria SP search-criteria
種類=["UID"SP]の「種類」SP種類評価基準SP検索評価基準
sort-criteria = "(" sort-criterion *(SP sort-criterion) ")"
種類評価基準は「(「種類評価基準*(SP種類評価基準)」)」と等しいです。
sort-criterion = ["REVERSE" SP] sort-key
種類評価基準=[SPを「逆にする」]分類用キー
sort-key = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" /
"SUBJECT" / "TO"
分類用キー=「到着」/「CC」/「日付」/“FROM"/「サイズ」/「対象」/“TO"
thread = ["UID" SP] "THREAD" SP thread-alg SP search-criteria
糸=["UID"SP]の「糸」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)
検索評価基準はcharset1*と等しいです。(SP検索キー)
charset = atom / quoted
; CHARSET values MUST be registered with IANA
charset=原子/引用される。 CHARSET値をIANAに示さなければなりません。
sort-data = "SORT" *(SP nz-number)
種類データは「種類」*と等しいです。(SP nz-数)
thread-data = "THREAD" [SP 1*thread-list]
糸データは「糸」と等しいです。[SP1*糸リスト]
Crispin & Murchison Standards Track [Page 14] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[14ページ]
thread-list = "(" (thread-members / thread-nested) ")"
「(「(糸で糸メンバー/入れ子にされる)」の)」という糸リスト=
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-refwd = ("re" / ("fw" ["d"])) *WSP [subj-blob] ":"
「首題-refwdは*WSP[首題一滴]と等し(「re」/(「fw[「d」]」)の)」:、」
subj-blob = "[" *BLOBCHAR "]" *WSP
「[「*BLOBCHAR」]」という首題一滴=*WSP
subj-fwd = subj-fwd-hdr subject subj-fwd-trl
首題-fwdは首題-fwd-hdrの対象の首題-fwd-trlと等しいです。
subj-fwd-hdr = "[fwd:"
首題-fwd-hdrが等しい、「[fwd:、」
subj-fwd-trl = "]"
「首題-fwd-trl=」]、」
subj-leader = (*subj-blob subj-refwd) / WSP
首題リーダー=(*首題一滴首題-refwd)/WSP
subj-middle = *subj-blob (subj-base / subj-fwd)
; last subj-blob is subj-base if subj-base would
; otherwise be empty
首題中央は*首題一滴(首題首題ベース/fwd)と等しいです。 首題ベースがベースであるなら、最後の首題一滴は首題ベースです。 さもなければ、空であってください。
subj-trailer = "(fwd)" / WSP
首題トレーラ=「(fwd)」/WSP
subj-base = NONWSP *(*WSP NONWSP)
; can be a subj-blob
首題ベースはNONWSP*と等しいです(*WSP NONWSP)。 首題一滴であることができます。
BLOBCHAR = %x01-5a / %x5c / %x5e-ff
; any CHAR8 except '[' and ']'.
; SHOULD comply with [UTF-8]
BLOBCHARは%x01-5a/%x5c/%x5e-ffと等しいです。 どんなCHAR8も除く、'、['']'。 ; SHOULDは従います。[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。 ; SHOULDは従います。[UTF-8]
6. Security Considerations
6. セキュリティ問題
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のプライバシー保護、またはある他の保護メカニズムで。
Crispin & Murchison Standards Track [Page 15] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[15ページ]
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によるソーティングが、縫うように通る木をミスリードするのに通じることができると認めるのは重要です。 例えば、偽の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.
ベース対象を抜粋する過程は抽出されたデータが対象の人工物と対照的に重要なテキストであったなら不正確な照合につながるかもしれません。
7. Internationalization Considerations
7. 国際化問題
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の規則に従わなければならないと述べるので。 iに従って、すなわち、SORTとTHREAD拡張子はストリングを照合しなければなりません; [UNICASEMAP]で説明されたユニコード-casemapの照合。 また、サーバSHOULDは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:」を推薦することに注意してください。 (ラテン語「resで」、意味、「その件、」、) 使用されて、回答を特定してください。 荒野で見つけられたかなりの変化が転送されたメッセージを特定する複数の形式の象徴から来ているのが、明白ですが、変化は(まだ)処理しやすいです。 その結果、それが示される、その「re:」 そして、対象の抽出が統治するベースによって支持されたフォワードへの象徴の変化の1つがインターネットメール・メッセージのために採用されて、以来そうするのは、ユーザのための象徴言語を局所化するようにそれを簡単な表示時間のタスクにします。
8. IANA Considerations
8. IANA問題
[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能力の登録を構成します。
Crispin & Murchison Standards Track [Page 16] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[16ページ]
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.
このドキュメントは新しい[IMAP]縫うように通るアルゴリズム登録を作成します。(それは、標準化過程を発行するのによるアルゴリズムかIESGによって承認された実験的なRFCに糸を通しながら、登録されます)。 このドキュメントはその登録でのORDEREDSUBJECTとREFERENCESアルゴリズムの登録を構成します。
9. Normative References
9. 引用規格
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
解放された[CHARSET]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、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.メリニコフ、「インターネットメッセージアクセス・プロトコル国際化」、RFC5255、2008年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[UNICASEMAP] Crispin, M., "i;unicode-casemap - Simple Unicode
Collation Algorithm", RFC 5051, October 2007.
[UNICASEMAP] クリスピン、M.、「i; ユニコード-casemap--簡単なユニコード照合アルゴリズム」、RFC5051、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、ISO10646の変化形式」STD63、RFC3629、11月2003日
10. Informative References
10. 有益な参照
[IMAP-MODELS] Crispin, M., "Distributed Electronic Mail Models in
IMAP4", RFC 1733, December 1994.
[IMAP-モデル]クリスピン(M.)は「1994年12月にIMAP4"、RFC1733で電子メールモデルを分配しました」。
[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。
Crispin & Murchison Standards Track [Page 17] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[17ページ]
Authors' Addresses
作者のアドレス
Mark R. Crispin Panda Programming 6158 NE Lariat Loop Bainbridge Island, WA 98110-2098
マークのR.クリスピンパンダプログラミング6158Neラリエット輪のベーンブリッジ島、ワシントン98110-2098
Phone: +1 (206) 842-2385 EMail: IMAP+SORT+THREAD@Lingling.Panda.COM
以下に電話をしてください。 +1 (206) 842-2385 メールしてください: IMAP+種類+ THREAD@Lingling.Panda.COM
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213
ピッツバーグ、ケネスマーチソンカーネギーメロン大学5000フォーブズアベニューCyert Hall285PA 15213
Phone: +1 (412) 268-2638 EMail: murch@andrew.cmu.edu
以下に電話をしてください。 +1 (412) 268-2638 メールしてください: murch@andrew.cmu.edu
Crispin & Murchison Standards Track [Page 18] RFC 5256 IMAP Sort June 2008
クリスピンとRFC5256IMAPが2008年6月に割り当てるマーチソン標準化過程[18ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Crispin & Murchison Standards Track [Page 19]
クリスピンとマーチソン標準化過程[19ページ]
一覧
スポンサーリンク
