[要約] RFC 5267は、IMAP4のコンテキストに関する情報を提供するためのものであり、IMAP4クライアントとサーバー間の通信の理解を支援します。
Network Working Group D. Cridland
Request for Comments: 5267 C. King
Category: Standards Track Isode Limited
July 2008
Contexts for IMAP4
IMAP4のコンテキスト
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
概要
The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes.
IMAP4REV1プロトコルには、コアプロトコルの一部として強力な検索機能がありますが、簡単に処理できるライブで更新された結果を作成する機能がありません。このメモはそのような拡張機能を提供し、仮想メールボックスに似た施設を提供するために使用する方法を示しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Extended Sort Syntax . . . . . . . . . . . . . . . . . . . . . 3
3.1. ESORT Extension . . . . . . . . . . . . . . . . . . . . . 4
3.2. Ranges in Extended Sort Results . . . . . . . . . . . . . 4
3.3. Extended SORT Example . . . . . . . . . . . . . . . . . . 4
4. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Context Hint . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Notifications of Changes . . . . . . . . . . . . . . . . . 6
4.3.1. Refusing to Update Contexts . . . . . . . . . . . . . 7
4.3.2. Common Features of ADDTO and REMOVEFROM . . . . . . . 8
4.3.3. ADDTO Return Data Item . . . . . . . . . . . . . . . . 8
4.3.4. REMOVEFROM Return Data Item . . . . . . . . . . . . . 9
4.3.5. The CANCELUPDATE Command . . . . . . . . . . . . . . . 10
4.4. Partial Results . . . . . . . . . . . . . . . . . . . . . 10
4.5. Caching Results . . . . . . . . . . . . . . . . . . . . . 11
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Cookbook . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Virtual Mailboxes . . . . . . . . . . . . . . . . . . . . 15
A.2. Trash Mailboxes . . . . . . . . . . . . . . . . . . . . . 15
A.3. Immediate EXPUNGE Notifications . . . . . . . . . . . . . 15
A.4. Monitoring Counts . . . . . . . . . . . . . . . . . . . . 15
A.5. Resynchronizing Contexts . . . . . . . . . . . . . . . . . 16
Appendix B. Server Implementation Notes . . . . . . . . . . . . . 16
Although the basic SEARCH command defined in [IMAP], and as enhanced by [ESEARCH], is relatively compact in its representation, this reduction saves only a certain amount of data, and huge mailboxes might overwhelm the storage available for results on even relatively high-end desktop machines.
[IMAP]で定義された基本的な検索コマンド、および[ESEarch]によって強化されたように、その表現は比較的コンパクトですが、この削減は一定のデータのみを節約し、巨大なメールボックスは比較的高い結果で利用可能なストレージを圧倒する可能性があります-ENDデスクトップマシン。
The SORT command defined in [SORT] provides useful features, but is hard to use effectively on changing mailboxes over low-bandwidth connections.
[sort]で定義されているソートコマンドは、有用な機能を提供しますが、低帯域幅接続上のメールボックスの変更に効果的に使用するのは困難です。
This memo borrows concepts from [ACAP], such as providing a windowed view onto search or sort results, and making updates that are bandwidth and round-trip efficient. These are provided by two extensions: "ESORT" and "CONTEXT".
このメモは、[ACAP]から概念を借りて、検索またはソートの結果にウィンドウビューを提供したり、帯域幅と往復効率の高い更新を作成したりします。これらは、「ESORT」と「コンテキスト」の2つの拡張機能によって提供されます。
In examples, "C:" and "S:" indicate lines sent by the client messaging user agent and IMAP4rev1 ([IMAP]) server, respectively. "//" indicates inline comments not part of the protocol exchange. Line breaks are liberally inserted for clarity. Examples are intended to be read in order, such that the state remains from one example to the next.
例では、「C：」と「S：」は、それぞれクライアントメッセージングユーザーエージェントとIMAP4REV1（[IMAP]）サーバーによって送信された行を示します。「//」は、プロトコル交換の一部ではないインラインコメントを示します。ラインブレークは、明確にするために自由に挿入されます。例は、状態がある例から次の例に残るように、順番に読むことを目的としています。
Although the examples show a server that supports [ESEARCH], this is not a strict requirement of this specification.
例は[ESEarch]をサポートするサーバーを示していますが、これはこの仕様の厳格な要件ではありません。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[キーワード]で説明されていると解釈されます。
Other capitalized words are typically names of IMAP extensions or commands -- these are uppercased for clarity only, and are case-insensitive.
他の大文字の単語は通常、IMAP拡張またはコマンドの名前です - これらは明確になるためにのみ高く評価されており、ケース非感受性です。
Servers implementing the extended SORT provide a suite of extensions to the SORT and UID SORT commands defined in [SORT]. This allows for return options, as used with SEARCH and specified in [IMAP-ABNF], to be used with SORT in a similar manner.
拡張ソートを実装するサーバーは、[ソート]で定義されているソートおよびUIDソートコマンドに一連の拡張機能を提供します。これにより、検索で使用され、[IMAP-ABNF]で指定されているリターンオプションが、同様の方法でソートで使用できます。
The SORT and UID SORT commands are extended by the addition of an optional list of return options that follow a RETURN atom immediately after the command. If this is missing, the server will return results as specified in [SORT].
ソートとUIDのソートコマンドは、コマンドの直後に戻る原子に従うオプションのリターンオプションのリストを追加することにより拡張されます。これが欠落している場合、サーバーは[sort]で指定されているように結果を返します。
The extended SORT command always returns results in the requested sort order, but is otherwise identical in its behaviour to the extended SEARCH command defined in [IMAP-ABNF], as extended by [ESEARCH]. In particular, the extended SORT command returns results in an ESEARCH response.
拡張ソートコマンドは常に要求されたソート順序で結果を返しますが、[esearch]によって拡張された[imap-abnf]で定義された拡張検索コマンドとその動作において同一です。特に、拡張ソートコマンドは、eSearch応答を返します。
Servers advertising the capability "ESORT" support the return options specified in [ESEARCH] in the SORT command. These return options are adapted as follows:
「エスコート」を宣伝するサーバーは、ソートコマンドの[Research]で指定されたリターンオプションをサポートしています。これらの返品オプションは、次のように適合しています。
MIN Return the message number/UID of the lowest sorted message satisfying the search criteria.
min検索基準を満たす最低ソートされたメッセージのメッセージ番号/uidを返します。
MAX Return the message number/UID of the highest sorted message satisfying the search criteria.
maxは、検索基準を満たす最高のソートされたメッセージのメッセージ番号/uidを返します。
ALL Return all message numbers/UIDs which match the search criteria, in the requested sort order, using a sequence-set. Note the use of ranges described below in Section 3.2.
すべては、シーケンスセットを使用して、要求されたソート順序で、検索条件に一致するすべてのメッセージ番号/UIDを返します。セクション3.2で以下に説明する範囲の使用に注意してください。
COUNT As in [ESEARCH].
[esearch]のようにカウントします。
Any ranges given by the server, including those given as part of the sequence-set, in an ESEARCH response resulting from an extended SORT or UID SORT command, MUST be ordered in increasing numerical order after expansion, as per usual [IMAP] rules.
サーバーから与えられた範囲は、拡張ソートまたはUIDソートコマンドに起因するeSearch応答のシーケンスセットの一部として与えられた範囲を含む、通常の[IMAP]規則に従って、拡張後に数値順序を増やして注文する必要があります。
In particular this means that 10:12 is equivalent to 12:10, and 10,11,12. To avoid confusion, servers SHOULD present ranges only when the first seq-number is lower than the second; that is, either of the forms 10:12 or 10,11,12 is acceptable, but 12:10 SHOULD be avoided.
特に、これは10:12が12:10および10,11,12に相当することを意味します。混乱を避けるために、サーバーは、最初のSEQ番号が2番目のものよりも低い場合にのみ範囲を表示する必要があります。つまり、フォーム10:12または10,11,12のいずれかが許容されますが、12：10は避ける必要があります。
If the list of return options is present but empty, then the server provides the ALL return data item in an ESEARCH response. This is functionally equivalent to an unextended UID SORT command, but can use a smaller representation:
リターンオプションのリストが存在するが空の場合、サーバーはeSearch応答ですべての返品データ項目を提供します。これは、機能的に拡張されたUIDソートコマンドと同等ですが、より小さな表現を使用できます。
C: E01 UID SORT RETURN () (REVERSE DATE) UTF-8 UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "E01") UID ALL 23765,23764,23763,23761,[...]
S: E01 OK Sort completed
Note that the initial three results are not represented as the range 23765:23763 as mandated in Section 3.2.
最初の3つの結果は、セクション3.2で義務付けられているように、範囲23765：23763として表されないことに注意してください。
The Contexts extension is present in any IMAP4rev1 server that includes the string "CONTEXT=SEARCH", and/or "CONTEXT=SORT", within its advertised capabilities.
コンテキスト拡張機能は、宣伝された機能内に、文字列「Context = search」および/または「Context = sort」を含むIMAP4REV1サーバーに存在します。
In the case of CONTEXT=SEARCH, the server supports the extended SEARCH command syntax described in [IMAP-ABNF], and accepts three additional return options.
コンテキスト=検索の場合、サーバーは[IMAP-ABNF]で説明されている拡張検索コマンド構文をサポートし、3つの追加の返品オプションを受け入れます。
Servers advertising CONTEXT=SORT also advertise the SORT capability, as described in [SORT], support the extended SORT command syntax described in Section 3, and accept three additional return options for this extended SORT.
サーバー広告のコンテキスト=ソート[ソート]で説明されているように、ソート機能も宣伝し、セクション3で説明されている拡張ソートコマンド構文をサポートし、この拡張ソートの3つの追加の返品オプションを受け入れます。
These additional return options allow for notifications of changes to the results of SEARCH or SORT commands, and also allow for access to partial results.
これらの追加の返品オプションにより、検索またはソートコマンドの結果の変更の通知が可能になり、部分的な結果へのアクセスが可能になります。
A server advertising the CONTEXT=SEARCH extension will order all SEARCH results, whether from a UID SEARCH or SEARCH command, in mailbox order -- that is, by message number and UID. Therefore, the UID SEARCH, SEARCH, UID SORT, or SORT command used -- collectively known as the searching command -- will always have an order, the requested order, which will be the mailbox order for UID SEARCH and SEARCH commands.
コンテキスト=検索拡張機能を宣伝するサーバーは、UID検索または検索コマンドからのすべての検索結果、つまりメッセージ番号とUIDによって注文されます。したがって、使用されているUID検索、検索、UIDソート、またはソートコマンド（検索コマンドと総称される）には、常に注文があります。これは、UID検索および検索コマンドのメールボックス注文です。
All of the return specifiers have no interaction with either each other or any return specifiers defined in [ESEARCH] or Section 3.1; however, it is believed that implementations supporting CONTEXT will also support ESEARCH and ESORT.
すべてのリターン仕様には、[ESEarch]またはセクション3.1で定義されている互いまたは返品指定子との相互作用はありません。ただし、コンテキストをサポートする実装は、ESEarchとESORTもサポートすると考えられています。
The return option CONTEXT SHOULD be used by a client to indicate that subsequent use of the search criteria are likely. Servers MAY ignore this return option or use it as a hint to maintain a full result cache, or index.
クライアントは、返されるオプションコンテキストを使用して、検索条件の後続の使用が可能性が高いことを示す必要があります。サーバーは、このリターンオプションを無視するか、完全な結果キャッシュまたはインデックスを維持するためのヒントとして使用する場合があります。
A client might choose to obtain a count of matching messages prior to obtaining actual results. Here, the client signals its intention to fetch the results themselves:
クライアントは、実際の結果を取得する前に、一致するメッセージのカウントを取得することを選択する場合があります。ここで、クライアントは結果を自分で取得する意図を示しています。
C: A01 SEARCH RETURN (CONTEXT COUNT) UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "A01") COUNT 23765
S: A01 OK Search completed.
The search return option UPDATE, if used by a client, causes the server to issue unsolicited notifications containing updates to the results that would be returned by an unmodified searching command. These update sets are carried in ADDTO and REMOVEFROM data items in ESEARCH responses.
検索リターンオプションの更新により、クライアントが使用する場合、サーバーは、変更されていない検索コマンドによって返される結果の更新を含む未承諾通知を発行します。これらのアップデートセットは、addtoで配信され、esearch応答でデータ項目を削除します。
These ESEARCH responses carry a search correlator of the searching command, hence clients MUST NOT reuse tags, as already specified in Section 2.2.1 of [IMAP]. An attempt to use UPDATE where a tag is already in use with a previous searching command that itself used UPDATE SHALL result in the server rejecting the searching command with a BAD response.
これらのesearch応答には、検索コマンドの検索相関者が含まれているため、[IMAP]のセクション2.2.1ですでに指定されているように、クライアントはタグを再利用してはなりません。使用した更新自体が以前の検索コマンドでタグが既に使用されている場合に更新を使用しようとすると、サーバーは悪い応答で検索コマンドを拒否します。
Both ADDTO and REMOVEFROM data items SHOULD be delivered to clients in a timely manner, as and when results change, whether by new messages arriving in the mailbox, metadata such as flags being changed, or messages being expunged.
データ項目の追加と削除の両方は、結果が変更されたときにタイムリーにクライアントに配信する必要があります。メールボックスに到着する新しいメッセージ、フラグの変更などのメタデータ、またはメッセージが削除されるかどうかにかかわらず。
Typically, this would occur at the same time as the FETCH, EXISTS, or EXPUNGE responses carrying the source of the change.
通常、これは、変化の原因を運ぶフェッチ、存在、または抹消された応答と同時に発生します。
Updates will cease when the mailbox is no longer selected, or when the CANCELUPDATE command, defined in Section 4.3.5, is issued by the client, whichever is sooner.
メールボックスが選択されなくなった場合、またはセクション4.3.5で定義されているCancelUpDateコマンドがクライアントによって発行された場合、どちらか早い方が発行された場合、更新は中止されます。
Unlike [ACAP], there is no requirement that a context need be created with CONTEXT to use UPDATE, and in addition, the lack of UPDATE with a CONTEXT does not affect the results caused by later searching commands -- there is no snapshot facility.
[ACAP]とは異なり、アップデートを使用するためにコンテキストでコンテキストを作成する必要はありません。さらに、コンテキストの更新の欠如は、後の検索コマンドによって引き起こされる結果に影響しません。スナップショット機能はありません。
There is no interaction between UPDATE and any other return options; therefore, use of RETURN (UPDATE MIN), for example, does not notify about the minimum UID or sequence number, but notifies instead about all changes to the set of matching messages. In particular, this means that a client using UPDATE and PARTIAL on the same search program could receive notifications about messages that do not currently interest it.
更新と他の返品オプションの間に相互作用はありません。したがって、たとえば、リターン（更新最小）の使用は、最小UIDまたはシーケンス番号について通知しませんが、一致するメッセージのセットのすべての変更について代わりに通知します。特に、これは、同じ検索プログラムでアップデートを使用して部分的に使用しているクライアントが、現在興味のないメッセージに関する通知を受信できることを意味します。
Finally, as specified in the errata to [IMAP], any message sequence numbers used in the search program are evaluated at the time the command is received; therefore, if the messages referred to by such message sequence numbers change, no notifications will be emitted.
最後に、[IMAP]から[IMAP]から[IMAP]から指定されているように、検索プログラムで使用されるメッセージシーケンス番号は、コマンドの受信時に評価されます。したがって、このようなメッセージシーケンス番号で言及されたメッセージが変更された場合、通知は放出されません。
This time, the client will require notifications of updates and chooses to obtain a count:
今回は、クライアントは更新の通知を必要とし、カウントを取得することを選択します。
C: B01 UID SEARCH RETURN (UPDATE COUNT) DELETED
KEYWORD $Junk
S: * ESEARCH (TAG "B01") COUNT 74
S: B01 OK Search completed, will notify.
// Note that the following is rejected, and has no effect:
C: B01 SORT RETURN (UPDATE) FLAGGED
S: B01 BAD Tag reuse
In some cases, the server MAY refuse to provide updates, such as if an internal limit on the number of update contexts is reached. In such a case, an untagged NO is generated during processing of the command with a response-code of NOUPDATE. The response-code contains, as argument, the tag of the search command for which the server is refusing to honour the UPDATE request.
場合によっては、サーバーは、更新コンテキストの数に内部制限に達するかなど、更新の提供を拒否する場合があります。そのような場合、NOUPDATEの応答コードを使用してコマンドの処理中に、未積層のNOが生成されます。応答コードには、引数として、サーバーが更新リクエストを尊重することを拒否している検索コマンドのタグが含まれています。
Other return options specified SHALL still be honoured.
指定されたその他の返品オプションは引き続き尊重されます。
Servers MUST provide at least one updating context per client, and SHOULD provide more -- see Appendix B for strategies on reducing the impact of additional updating contexts. Since sorted contexts require a higher implementation cost than unsorted contexts, refusal to provide updates for a SORT command does not imply that SEARCH contexts will also be refused.
サーバーは、クライアントごとに少なくとも1つの更新コンテキストを提供する必要があり、追加の更新コンテキストの影響を減らすための戦略については、付録Bを参照してください。ソートされたコンテキストでは、アンソートされていないコンテキストよりも高い実装コストが必要であるため、ソートコマンドの更新を提供することを拒否しても、検索コンテキストも拒否されることを意味しません。
This time, the client will require notifications of updates, and chooses to obtain a count:
今回は、クライアントは更新の通知を必要とし、カウントを取得することを選択します。
C: B02 UID SORT RETURN (UPDATE COUNT) UTF-8
KEYWORD $Junk
S: * ESEARCH (TAG "B02") COUNT 74
S: * NO [NOUPDATE "B02"] Too many contexts
S: B02 OK Search completed, will not notify.
Client handling might be to retry with a UID SEARCH command, or else cancel an existing context; see Section 4.3.5.
クライアントの取り扱いは、UID検索コマンドで再試行するか、既存のコンテキストをキャンセルすることです。セクション4.3.5を参照してください。
The result update set included in the return data item is specified as UIDs or message numbers, depending on how the UPDATE was specified. If the UPDATE was present in a SEARCH or SORT command, the results will be message numbers; in a UID SEARCH or UID SORT command, they will be UIDs.
Return Data Itemに含まれる結果の更新セットは、更新の指定方法に応じて、UIDまたはメッセージ番号として指定されます。更新が検索またはソートコマンドに存在する場合、結果はメッセージ番号になります。UID検索またはUIDソートコマンドでは、それらはUIDになります。
The client MUST process ADDTO and REMOVEFROM return data items in the order they appear, including those within a single ESEARCH response. Correspondingly, servers MUST generate ADDTO and REMOVEFROM responses such that the results are maintained in the requested order.
クライアントは、単一のesearch応答内のものを含め、表示される順序でデータ項目を返すことを処理および削除する必要があります。それに対応して、サーバーは、結果が要求された順序で維持されるように、Addtoおよびremoffrom応答を生成する必要があります。
As with any response aside from EXPUNGE, ESEARCH responses carrying ADDTO and/or REMOVEFROM return data items MAY be sent at any time. In particular, servers MAY send such responses when no command is in progress, during the processing of any command, or when the client is using the IDLE facility described in [IDLE]. Implementors are recommended to read [NOTIFY] as a mechanism for clients to signal servers that they are willing to process responses at any time, and are also recommended to pay close attention to Section 5.3 of [IMAP].
eSearch addtoおよび/またはremover fromデータ項目を運ぶeSearch応答は、eSearchの応答をいつでも送信することができます。特に、サーバーは、コマンドが進行中の場合、コマンドの処理中、または[アイドル]で説明されているアイドル施設を使用しているときに、そのような応答を送信する場合があります。実装者は、クライアントがいつでも応答を処理する意思があることをクライアントに信号を送るメカニズムとして[通知]を読むことをお勧めします。また、[IMAP]のセクション5.3に細心の注意を払うことをお勧めします。
It is anticipated that typical server implementations will emit ADDTO when they normally emit the causal FETCH or EXISTS, and similarly emit REMOVEFROM when they normally emit the causal FETCH or EXPUNGE.
典型的なサーバーの実装は、通常因果的なフェッチまたは存在を放出するときにADDTOを放出し、通常、因果的なフェッチまたは抹消を放出すると同様にremofiを放出することが予想されます。
The ADDTO return data item contains, as payload, a list containing pairs of a context position and a set of result updates in the requested order to be inserted at the context position. Where the searching command is a SEARCH or UID SEARCH command, the context position MAY be zero. Each pair is processed in the order that it appears.
Addto Return Data Itemには、ペイロードとして、コンテキスト位置のペアを含むリスト、およびコンテキスト位置に挿入される要求された順序での結果の更新が含まれます。検索コマンドが検索またはUID検索コマンドである場合、コンテキスト位置はゼロになる場合があります。各ペアは、表示される順に処理されます。
Note that an ADDTO containing message sequence numbers added as a result of those messages being delivered or appended MUST be sent after the EXISTS notification itself, in order that those sequence numbers are valid.
これらのメッセージが配信または追加された結果として追加されたメッセージシーケンス番号を含むAddtoは、それらのシーケンス番号が有効であるために、存在する通知自体の後に送信する必要があることに注意してください。
If the context position is non-zero, the result update is inserted at the given context position, meaning that the first result in the set will occupy the new context position after insertion, and any prior existing result at that context position will be shifted to a later context position.
コンテキストの位置がゼロでない場合、結果の更新は指定されたコンテキスト位置に挿入されます。つまり、セットの最初の結果は挿入後に新しいコンテキスト位置を占めることを意味し、そのコンテキスト位置での以前の既存の結果は後のコンテキスト位置。
Where the context position is zero, the client MAY insert the message numbers or UIDs in the result list such that the result list is maintained in mailbox order. In this case, servers are RECOMMENDED to order the result update into mailbox order to produce the shortest representation in set-syntax.
コンテキスト位置がゼロの場合、クライアントは結果リストにメッセージ番号またはUIDを挿入して、結果リストがメールボックスの順序で維持されるようにすることができます。この場合、サーバーは結果更新をメールボックス注文に注文して、セットシンタックスで最短の表現を生成することをお勧めします。
[...]
S: * 23762 FETCH (FLAGS (\Deleted \Seen))
S: * 23763 FETCH (FLAGS ($Junk \Seen))
S: * ESEARCH (TAG "B01") UID ADDTO (0 32768:32769)
Note that this example assumes messages 23762 and 23763 with UIDs 32768 and 32769 (respectively) previously had neither \Deleted nor $Junk set. Also note that only the ADDTO is included, and not the (now changed) COUNT.
この例では、UIDS 32768および32769（それぞれ）を使用したメッセージ23762および23763が想定されていることに注意してください（以前は\削除も$ジャンクセットもありませんでした。また、（現在変更された）カウントではなく、AddToのみが含まれていることに注意してください。
If the searching command "C01" initially generated a result list of 2734:2735, then the following three responses are equivalent, and yield a result list of 2731:2735:
検索コマンド「C01」が最初に2734：2735の結果リストを生成した場合、次の3つの応答は同等であり、2731：2735の結果リストを生成します。
[...]
S: * ESEARCH (TAG "C01") UID ADDTO (1 2733 1 2732 1 2731)
S: * ESEARCH (TAG "C01") UID ADDTO (1 2733) ADDTO (1 2731:2732)
S: * ESEARCH (TAG "C01") UID ADDTO (1 2731:2733)
The last is the preferred representation.
最後は好ましい表現です。
The REMOVEFROM return data item contains, as payload, a list containing pairs of a context position and a set of result updates in the requested order to be removed starting from the context position. Where the searching command is a SEARCH or UID SEARCH command, the context position MAY be zero. Each pair is processed in the order that it appears.
removerfrom return Dataアイテムには、ペイロードとして、コンテキスト位置のペアを含むリスト、およびコンテキスト位置から削除される要求された順序での結果の更新が含まれます。検索コマンドが検索またはUID検索コマンドである場合、コンテキスト位置はゼロになる場合があります。各ペアは、表示される順に処理されます。
If the context position is non-zero, the results are removed at the given context position, meaning that the first result in the set will occupy the given context position before removal, and any prior existing result at that context position will be shifted to an earlier context position.
コンテキストの位置がゼロでない場合、結果は指定されたコンテキスト位置で削除されます。つまり、セットの最初の結果は削除前に指定されたコンテキスト位置を占有し、そのコンテキスト位置での以前の既存の結果は以前のコンテキスト位置。
Where the context position is zero, the client removes the message numbers or UIDs in the result list wherever they occur, and servers are RECOMMENDED to order the result list in mailbox order to obtain the best benefit from the set-syntax.
コンテキストの位置がゼロの場合、クライアントは結果リストのメッセージ番号またはUIDを削除します。発生する場所では、サーバーは結果リストをメールボックスの注文で注文して、セットシンタックスの最良の利益を得ることをお勧めします。
Note that a REMOVEFROM containing message sequence numbers removed as a result of those messages being expunged MUST be sent prior to the expunge notification itself, in order that those sequence numbers remain valid.
これらのメッセージが削除された結果として削除されたメッセージシーケンス番号を削除することは、それらのシーケンス番号が有効なままであるために、抹消通知自体の前に送信する必要があることに注意してください。
Here, a message in the result list is expunged. The REMOVEFROM is shown to happen without any command in progress; see Section 4.3.2. Note that EXPUNGE responses do not have this property.
ここでは、結果リストのメッセージが削除されます。remoffromは、進行中のコマンドなしで発生することが示されています。セクション4.3.2を参照してください。抹消の応答にはこのプロパティがないことに注意してください。
[...]
S: * ESEARCH (TAG "B01") UID REMOVEFROM (0 32768)
C: B03 NOOP
S: * 23762 EXPUNGE
S: B03 OK Nothing done.
When a client no longer wishes to receive updates, it may issue the CANCELUPDATE command, which will prevent all updates to the contexts named in the arguments from being transmitted by the server. The command takes, as arguments, one or more tags of the commands used to request updates.
クライアントが更新を受信したくない場合、CancelUpDateコマンドを発行する可能性があります。これにより、引数に付随するコンテキストのすべての更新がサーバーによって送信されないようになります。コマンドは、引数として、更新を要求するために使用されるコマンドの1つ以上のタグを取得します。
The server MAY free any resource associated with a context so disabled -- however, the client is free to issue further searching commands with the same criteria and requested order, including PARTIAL requests.
サーバーは、無効化されたコンテキストに関連付けられたリソースを無料で解放できます。ただし、クライアントは、同じ基準でコマンドをさらに検索し、部分的なリクエストを含む注文を要求することができます。
C: B04 CANCELUPDATE "B01"
S: B04 OK No further updates.
The PARTIAL search return option causes the server to provide in an ESEARCH response a subset of the results denoted by the sequence range given as the mandatory argument. The first result is 1; thus, the first 500 results would be obtained by a return option of "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This intentionally mirrors message sequence numbers.
部分的な検索リターンオプションにより、サーバーはeSearch応答で、必須引数として与えられたシーケンス範囲で示される結果のサブセットを提供します。最初の結果は1です。したがって、最初の500の結果は、「部分的な1：500」のリターンオプション、2番目の500が「部分501：1000」によって得られます。これは、メッセージシーケンス番号を意図的に反映しています。
A single command MUST NOT contain more than one PARTIAL or ALL search return option -- that is, either one PARTIAL, one ALL, or neither PARTIAL nor ALL is allowed.
単一のコマンドには、部分的またはすべての検索リターンオプション、つまり、部分的、1つ、またはすべてが許可されていないかのいずれかを含めることはできません。
For SEARCH results, the entire result list MUST be ordered in mailbox order, that is, in UID or message sequence number order.
検索結果の場合、結果リスト全体をメールボックスの順序、つまりUIDまたはメッセージシーケンス番号の順序で注文する必要があります。
Where a PARTIAL search return option references results that do not exist, by using a range which starts or ends higher than the current number of results, then the server returns the results that are in the set. This yields a PARTIAL return data item that has, as payload, the original range and a potentially missing set of results that may be shorter than the extent of the range.
部分的な検索リターンオプションが存在しない結果を参照する場合、現在の結果よりも高く開始または終了する範囲を使用して、サーバーはセットにある結果を返します。これにより、ペイロードとして、元の範囲と潜在的に欠落している結果セットが範囲の範囲よりも短い場合がある部分的な返品データ項目が得られます。
Clients need not request PARTIAL results in any particular order. Because mailboxes may change, clients will often wish to use PARTIAL in combination with UPDATE, especially if the intent is to walk a large set of results; however, these return options do not interact -- the UPDATE will provide notifications for all matching results.
クライアントは、特定の順序で部分的な結果を要求する必要はありません。メールボックスが変更される可能性があるため、クライアントは、特に大量の結果を歩くことを目的としている場合、更新と組み合わせて部分的に使用したいことがよくあります。ただし、これらのリターンオプションは相互作用しません。更新は、すべてのマッチング結果の通知を提供します。
// Recall from A01 that there are 23764 results.
C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED
UNKEYWORD $Junk
C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED
UNKEYWORD $Junk
C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED
UNKEYWORD $Junk
S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...)
// 264 results in set syntax elided,
// this spans the end of the results.
S: A02 OK Completed.
S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...)
// 500 results in set syntax elided.
S: A03 OK Completed.
S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL)
// No results are present, this is beyond the end of the results.
S: A04 OK Completed.
Server implementations MAY cache results from a SEARCH or SORT, whether or not hinted to by CONTEXT, in order to make subsequent searches more efficient, perhaps by recommencing a subsequent PARTIAL search where a previous search left off. However, servers MUST behave identically whether or not internal caching is taking place; therefore, any such cache is required to be updated as changes to the mailbox occur. An alternate strategy would be to discard results when any change occurs to the mailbox.
サーバーの実装では、以前の検索が中断された後続の部分検索を推奨することにより、後続の検索をより効率的にするために、コンテキストによって示唆されるかどうかにかかわらず、検索またはソートの結果をキャッシュする場合があります。ただし、サーバーは、内部キャッシュが行われているかどうかにかかわらず、同じように動作する必要があります。したがって、このようなキャッシュは、メールボックスの変更が発生するため、更新する必要があります。別の戦略は、メールボックスに変更が発生した場合に結果を破棄することです。
The collected formal syntax. This uses ABNF as defined in [ABNF]. It includes definitions from [IMAP], [IMAP-ABNF], and [SORT].
収集された正式な構文。これは、[ABNF]で定義されているABNFを使用します。[IMAP]、[IMAP-ABNF]、および[ソート]の定義が含まれています。
capability =/ "CONTEXT=SEARCH" / "CONTEXT=SORT" / "ESORT"
;; <capability> from [IMAP]
command-select =/ "CANCELUPDATE" 1*(SP quoted)
;; <command-select> from [IMAP]
context-position = number
;; Context position may be 0 for SEARCH result additions.
;; <number> from [IMAP]
modifier-context = "CONTEXT"
modifier-partial = "PARTIAL" SP partial-range
modifier-partial = "partial" sp partial-range
partial-range = nz-number ":" nz-number
;; A range 500:400 is the same as 400:500.
;; This is similar to <seq-range> from [IMAP],
;; but cannot contain "*".
modifier-update = "UPDATE"
search-return-opt =/ modifier-context / modifier-partial /
modifier-update
;; All conform to <search-return-opt>, from [IMAP-ABNF]
resp-text-code =/ "NOUPDATE" SP quoted
;; <resp-text-code> from [IMAP]
ret-data-addto = "ADDTO"
SP "(" context-position SP sequence-set
*(SP context-position SP sequence-set)
")"
;; <sequence-set> from [IMAP]
ret-data-partial = "PARTIAL" SP "(" partial-range SP partial-results ")" ;; <partial-range> is the requested range.
ret-data-partial = "partial" sp "（" partial-range sp partial-results "）" ;;<Partial-Range>は要求された範囲です。
partial-results = sequence-set / "NIL" ;; <sequence-set> from [IMAP] ;; NIL indicates no results correspond to the requested range.
partial-results = sequence-set / "nil" ;;<sequence-set> from [imap] ;;NILは、要求された範囲に対応する結果がないことを示します。
ret-data-removefrom = "REMOVEFROM"
SP "(" context-position SP sequence-set
*(SP context-position SP sequence-set)
")"
;; <sequence-set> from [IMAP]
search-return-data =/ ret-data-partial / ret-data-addto /
ret-data-removefrom
;; All conform to <search-return-data>, from [IMAP-ABNF]
sort =/ extended-sort
;; <sort> from [SORT]
extended-sort = ["UID" SP] "SORT" search-return-opts
SP sort-criteria SP search-criteria
;; <search-return-opts> from [IMAP-ABNF]
;; <sort-criteria> and <search-criteria> from [SORT]
This document defines additional IMAP4 capabilities. As such, it does not change the underlying security considerations of [IMAP]. The authors and reviewers believe that no new security issues are introduced with these additional IMAP4 capabilities.
このドキュメントでは、追加のIMAP4機能を定義しています。そのため、[IMAP]の基礎となるセキュリティ上の考慮事項は変更されません。著者とレビュアーは、これらの追加のIMAP4機能については、新しいセキュリティの問題が導入されていないと考えています。
Creation of a large number of contexts may provide an avenue for denial-of-service attacks by authorized users. Implementors may reduce this by limiting the number of contexts possible to create, via the protocol features described in Section 4.3.1; by reducing the impact of contexts by the implementation strategies described in Appendix B; and by logging context creation and usage so that administrative remedies may be applied.
多数のコンテキストの作成は、認定ユーザーによるサービス拒否攻撃の道を提供する場合があります。実装者は、セクション4.3.1で説明したプロトコル機能を介して、作成できるコンテキストの数を制限することにより、これを減らすことができます。付録Bに記載されている実装戦略によるコンテキストの影響を減らすことにより。そして、管理救済策を適用できるように、コンテキストの作成と使用法を記録することにより。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC.
IMAP4機能は、標準トラックまたはIESGが承認した実験RFCを公開することにより登録されます。
This document defines the ESORT, CONTEXT=SEARCH, and CONTEXT=SORT IMAP capabilities. IANA has added them to the registry accordingly.
このドキュメントでは、ESORT、CONTEXT = SEARCH、およびCONTEXT = SORT IMAP機能を定義します。IANAはそれに応じてレジストリにそれらを追加しました。
Much of the design of this extension can be found in ACAP. Valuable comments, both in agreement and in dissent, were received from Alexey Melnikov, Arnt Gulbrandsen, Cyrus Daboo, Filip Navara, Mark Crispin, Peter Coates, Philip Van Hoof, Randall Gellens, Timo Sirainen, Zoltan Ordogh, and others, and many of these comments have had significant influence on the design or the text. The authors are grateful to all those involved, including those not mentioned here.
この拡張機能の設計の多くは、ACAPにあります。同意と反対の両方で、Alexey Melnikov、Arnt Gulbrandsen、Cyrus Daboo、Filip Navara、Mark Crispin、Peter Coates、Philip Van Hoof、Randall Gellens、Timo Sirainen、Zoltan Ordoghなどから、Alexey Melnikov、Arnt Gulbrandsen、Filip Navara、Mark Crispin、その他から貴重なコメントが受けられました。これらのコメントは、デザインまたはテキストに大きな影響を与えています。著者は、ここで言及されていないものを含め、関係者全員に感謝しています。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF：STD 68、RFC 5234、2008年1月。
[ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[Esearch] Melnikov、A。、およびD. Cridland、「IMAP4拡張は、どのような種類の情報が返されるかを制御するための検索コマンドへ」、RFC 4731、2006年11月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IMAP-ABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAP-ABNF] Melnikov、A。およびC. Daboo、「IMAP4 ABNFへの拡張を収集した」、RFC 4466、2006年4月。
[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月。
[SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[sort] Crispin、M。and K. Murchison、「インターネットメッセージアクセスプロトコル - ソートおよびスレッド拡張機能」、RFC 5256、2008年6月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[アイドル] Leiba、B。、「IMAP4 IDLEコマンド」、RFC 2177、1997年6月。
[NOTIFY] Melnikov, A., Gulbrandsen, A., and C. King, "The IMAP NOTIFY Extension", Work in Progress, March 2008.
[Notify] Melnikov、A.、Gulbrandsen、A。、およびC. King、「IMAP Notify Extension」、2008年3月の作業。
It is possible to use the facilities described within this memo to create a facility largely similar to a virtual mailbox, but handled on the client side.
このメモ内で説明されている機能を使用して、仮想メールボックスに大きく似た機能を作成することができますが、クライアント側で処理されます。
Initially, the client SELECTs the real "backing" mailbox. Next, it can switch to a filtered view at any time by issuing a RETURN (COUNT UPDATE CONTEXT), and using RETURN (PARTIAL x:y) as the user scrolls, feeding the results into a FETCH as required to populate summary views.
最初に、クライアントは実際の「バッキング」メールボックスを選択します。次に、リターン（カウントアップデートコンテキスト）を発行し、ユーザーがスクロールしてリターン（部分X：Y）を使用して、要約ビューを入力するために必要に応じて結果をフェッチにフィードすることにより、いつでもフィルタービューに切り替えることができます。
A typically useful view is "UID SORT (DATE) RETURN (...) UTF-8 UNSEEN UNDELETED", which can be used to show the mailbox sorted into INTERNALDATE order, filtered to only show messages which are unread and not yet deleted.
一般的に有用なビューは、「uid sort（date）return（...）utf-8 Unseen Undeleted」です。これは、内部デート順序にソートされたメールボックスを表示するために使用できます。
Certain contexts are particularly useful for client developers wishing to present something similar to the common trash mailbox metaphor in limited bandwidth. The simple criteria of UNDELETED only matches undeleted messages, and the corresponding DELETED search key can be used to display a per-mailbox trash-like virtual mailbox.
特定のコンテキストは、限られた帯域幅の一般的なゴミメールボックスメタファーに似たものを提示したいクライアント開発者にとって特に役立ちます。未定の単純な基準は、未定のメッセージのみに一致し、対応する削除された検索キーを使用して、Mailboxごとのゴミ箱のような仮想メールボックスを表示できます。
The command "SEARCH RETURN (UPDATE) ALL" can be used to create a context that notifies immediately about expunged messages, yet will not affect message sequence numbers until the normal EXPUNGE message can be sent. This may be useful for clients wishing to show this behavior without losing the benefit of sequence numbering.
コマンド「検索リターン（更新）ALL」を使用して、削除されたメッセージについてすぐに通知するコンテキストを作成できますが、通常の抹消メッセージを送信するまでメッセージシーケンス番号には影響しません。これは、シーケンス番号の恩恵を失うことなく、この動作を示したいクライアントに役立つ場合があります。
A client need not maintain any result cache at all, but instead it can maintain a simple count of messages matching the search criteria. Typically, this would use the SEARCH command, as opposed to UID SEARCH, due to its smaller representation. Such usage might prove useful in monitoring the number of flagged, but unanswered, messages, for example, with "SEARCH RETURN (UPDATE COUNT) FLAGGED UNANSWERED".
クライアントは結果キャッシュをまったく維持する必要はありませんが、代わりに、検索条件に一致するメッセージの単純なカウントを維持できます。通常、これは、表現が小さいため、UID検索とは対照的に検索コマンドを使用します。このような使用法は、たとえば「検索リターン（更新カウント）にフラグを立てられていない」というフラグが付けられていないが未回答のメッセージの数を監視するのに役立つ可能性があります。
The creation of a context, and immediate access to it, can all be accomplished in a single round-trip. Therefore, whilst it is possible to elide resynchronization if no changes have occurred, it is simpler in most cases to resynchronize by simply recreating the context.
コンテキストの作成とそれへの即時アクセスは、すべて1回の往復で達成できます。したがって、変更が発生していない場合、再同期を排除することは可能ですが、ほとんどの場合、コンテキストを単に再現するだけで再同期することがより簡単です。
Although a server may cache the results, this is neither mandated nor required, especially when the client uses SEARCH or UID SEARCH commands. UPDATE processing, for example, can be achieved efficiently by comparison of the old flag state (if any) and the new, and PARTIAL can be achieved by re-running the search until the suitable window is required. This is a result of there being no snapshot facility.
サーバーは結果をキャッシュする場合がありますが、特にクライアントが検索コマンドまたはUID検索コマンドを使用する場合、これは義務付けられておらず、必須ではありません。たとえば、更新処理は、古い旗の状態（もしあれば）と新しいものと、適切なウィンドウが必要になるまで検索を再ランニングすることで実現できます。これは、スナップショット施設がなかった結果です。
For example, on a new message, the server can simply test for matches against all current UPDATE context search programs, and for any that match, send the ADDTO return data.
たとえば、新しいメッセージでは、サーバーは、現在のすべての更新コンテキスト検索プログラムとの一致をテストするだけで、その一致する場合は、AddTo返信データを送信できます。
Similarly, for a flag change on an existing message, the server can check whether the message matched with its old flags, whether it matches with new flags, and provide ADDTO or REMOVEFROM return data accordingly if these results differ.
同様に、既存のメッセージのフラグ変更の場合、サーバーは、メッセージが古いフラグと一致するかどうか、新しいフラグと一致するかどうかを確認し、これらの結果が異なる場合にそれに応じてaddtoまたはremotionデータを提供することができます。
For PARTIAL requests, the server can perform a full search, discarding results until the lower bound is hit, and stopping the search when sufficient results have been obtained.
部分的な要求の場合、サーバーは完全な検索を実行し、下限がヒットするまで結果を破棄し、十分な結果が得られたときに検索を停止できます。
With some additional state, it is possible to restart PARTIAL searches, thus avoiding performing the initial discard phase.
いくつかの追加の状態では、部分的な検索を再開することが可能であるため、初期廃棄段階の実行を回避できます。
For the best performance, however, caching the full search results is needed, which can allow for faster responses at the expense of memory. One reasonable strategy would be to balance this trade-off at run-time, discarding search results after a suitable timeout, and regenerating them as required.
ただし、最高のパフォーマンスをするには、完全な検索結果をキャッシュする必要があります。これにより、メモリを犠牲にしてより速い応答が可能になります。合理的な戦略の1つは、実行時にこのトレードオフのバランスを取り、適切なタイムアウト後に検索結果を破棄し、必要に応じてそれらを再生することです。
This yields state requirements of storing the search program for any UPDATE contexts, and optionally storing both search program and (updated) results for further contexts as required.
これにより、更新コンテキストの検索プログラムを保存し、必要に応じてさらにコンテキストの検索プログラムと（更新）結果の両方を保存するという州の要件が得られます。
Note that in the absence of a server-side results cache, it may be impossible to know if an expunged message previously matched unless the original message is still available. Therefore, some implementations may be forced into using a results cache in many circumstances.
サーバー側の結果キャッシュがない場合、元のメッセージがまだ利用可能でない限り、削除されたメッセージが以前に一致したかどうかを知ることは不可能かもしれません。したがって、いくつかの実装は、多くの状況で結果キャッシュの使用を強制される場合があります。
UPDATE contexts created with SORT or UID SORT will almost certainly require some form of results caching, however.
ただし、sortまたはuidソートで作成されたコンテキストを更新するには、ほぼ確実に何らかの形の結果キャッシュが必要です。
Authors' Addresses
著者のアドレス
Dave Cridland Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB
Dave Cridland Isode Limited 5 Castle Business Village 36、Station Road Hampton、Middlesex TW12 2BX GB
EMail: dave.cridland@isode.com
Curtis King Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB
カーティスキングアイソードリミテッド5キャッスルビジネスビレッジ36、ステーションロードハンプトン、ミドルセックスTW12 2BX GB
EMail: cking@mumbo.ca
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への情報をお問い合わせください。