Network Working Group A. Melnikov
Request for Comments: 5466 C. King
Category: Standards Track Isode Ltd
February 2009
IMAP4 Extension for Named Searches (Filters)
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter.
文書には、永続的ストアという名前のIMAP（RFC 3501）への道は、サーバー上で検索を定義します。このような名前の検索は、その後検索やパラメータなどの検索条件を受け入れ、他のコマンドで参照することができます。
Table of Contents
目次
1. Introduction and Overview . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . . 2
3.1. FILTER SEARCH Criterion . . . . . . . . . . . . . . . . . . 3
3.2. Managing Filters Using SETMETADATA/GETMETADATA Commands . . 4
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Persistent named searches described in this document allow clients to save favorite searches on the server. Such saved searches can save bandwidth for clients that need to regularly repeat them.
この文書で説明する永続的な名前の検索では、クライアントがサーバー上でお気に入りの検索を保存することができます。このような保存された検索は、定期的に繰り返す必要があるクライアントの帯域幅を節約することができます。
The FILTERS IMAP extension adds a new FILTER search criterion for referencing persistent named searches (a.k.a. "filters"), as well as reuses GETMETADATA/SETMETADATA commands [METADATA] for listing/ creating/updating/deleting such filters.
FILTERSのIMAP拡張は、永続的な名前の検索（別称、「フィルター」）を参照するための新しいフィルタの検索条件を追加するだけでなく、上場/作成/更新/このようなフィルタを削除するためのgetMetaData / SETMETADATAコマンド[METADATA]を再利用します。
A filter can be private (only accessible to the logged-in user) or public (accessible to all logged-in users). Both a private and a public filter with the same name can exist at the same time. If both filter types with the same name exist, the FILTER SEARCH criterion (see Section 3.1) MUST use the value of the private filter; otherwise, it MUST use the value of the filter that exists.
フィルタは、（ログインしているすべてのユーザーがアクセス）プライベート（ログインしているユーザーにのみアクセス可能）またはパブリックにすることができます。民間と同じ名前を持つパブリックフィルタの両方が同時に存在することができます。同じ名前の両方のフィルタタイプが存在する場合は、フィルタの検索基準はプライベートフィルタの値を使用する必要があります（3.1節を参照します）。それ以外の場合は、存在フィルタの値を使用しなければなりません。
Let us call a pair of filter name and filter type a "typed filter". Each typed filter can have a value (which is a valid IMAP SEARCH criteria conforming to ABNF for the "search-criteria" non-terminal) and an optional human-readable description. The SETMETADATA command creates or updates the value and/or the description of a typed filter.
私たちは、フィルタ名とフィルタタイプ「と入力フィルタ」のペアを呼ぶことにしましょう。各入力されたフィルタは、オプションで判読可能な説明（非ターミナル「検索条件」のためのABNFに準拠した有効なIMAPの検索条件である）の値を持つことができます。 SETMETADATA指令値及び/又は型付きフィルタの説明を作成または更新します。
Values of all search keys stored in a filter MUST be encoded in UTF-8.
フィルタに記憶されている全ての検索キーの値は、UTF-8でエンコードされなければなりません。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。シングル「C：」場合や「S：」ラベルは複数行に適用され、その後、これらの線の間の改行は編集上明確にするためであり、実際のプロトコル交換の一部ではありません。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Basic familiarity with the METADATA-SERVER extension [METADATA] and terms defined therein is required to understand this document.
メタデータサーバ拡張[METADATA]およびそこに定義された用語の基本的な知識は、この文書を理解することが必要です。
The IMAP extension for persistent named searches is present in any IMAP4 implementation that advertises "FILTERS" as one of the supported capabilities in the CAPABILITY response or response code.
永続的な名前の検索のIMAP拡張は、CAPABILITY応答または応答コードでサポートされている機能の一つとして、「フィルタ」を宣伝するいかなるIMAP4の実装に存在しています。
The FILTER criterion for the SEARCH command allows a client to reference by name a filter stored on the server. Such filter was created by setting the server annotation named "/private/filters/ values/<filter_name>" (or the server annotation "/shared/filters/ values/<filter_name>", if "/private/filters/values/<filter_name>" doesn't exist) using the SETMETADATA command as described in Section 3.2.
SEARCHコマンドのためのフィルタ基準は、クライアントが名前でサーバに保存されているフィルタを参照することができます。 「/プライベート/フィルター/値/ <場合、このようなフィルタは、「/プライベート/フィルター/値/ <FILTER_NAME>」という名前のサーバー注釈（またはサーバ注釈「/共有/フィルター/値/ <FILTER_NAME>」を設定することで作成されました3.2節で説明したようにFILTER_NAME>」SETMETADATAコマンドを使用して）存在しません。
Syntax: FILTER <filter_name>
構文：FILTER <FILTER_NAME>
When the named filter exists, its search criterion (i.e., the associated entry value) is inserted verbatim instead of the FILTER search-key. For example, the following SEARCH command
名前のフィルタが存在する場合、その検索条件（即ち、関連するエントリ値）の代わりにFILTER検索キーの逐語的に挿入されます。たとえば、次の検索コマンド
C: a SEARCH UID 300:900 FILTER on-the-road SINCE "3-Dec-2002"
C：検索UID 300：900 FILTER路上 "3 - 12月-2002" SINCE
would be equivalent to the following
以下に相当します
C: a SEARCH UID 300:900 OR SMALLER 5000 FROM "boss@example.com" SINCE "3-Dec-2002"
C：検索UID 300：900 OR "3-12月-2002" SINCE "boss@example.com" FROM 5000 SMALLER
assuming the filter "on-the-road" exists and contains the value 'OR SMALLER 5000 FROM "boss@example.com"'.
「オン・ザ・ロード」フィルタを想定して存在し、値「OR 『boss@example.com』 FROM 5000 SMALLER」が含まれています。
A reference to a nonexistent or unaccessible (e.g., due to access control restrictions) filter MUST cause failure of the SEARCH command with the tagged NO response that includes the UNDEFINED-FILTER response code followed by the name of the nonexistent/unaccessible filter.
存在しないかアクセス不能への参照（例えば、によるアクセス制御制限に）フィルタが存在しない/アクセスできないフィルタの名前が続くUNDEFINEDフィルタ応答コードを含むタグ付けされたNO応答でSEARCHコマンドの失敗を引き起こすしなければなりません。
Note the server SHOULD verify that each search criterion referenced by the FILTER search key is a full and correct search criterion. For example, the server should fail the SEARCH command if its SEARCH criterion references a filter containing "OR SMALLER" search criterion, because this value is lacking one parameter and thus is not a fully specified search criterion.
サーバがFILTER検索キーによって参照される各検索基準は、完全かつ正確な検索条件であることを確認する必要があります注意してください。その検索基準は、この値は一つのパラメータを欠いているので、「以下」の検索条件を含むフィルタを参照するので、完全に指定された検索基準ではない場合たとえば、サーバーは、検索コマンドを失敗するはずです。
Note that a named filter itself can reference another filter using the FILTER search-key. Implementations MUST be able to perform at least 3 substitution passes on the SEARCH command criterion. If an implementation allows for more passes, it MUST implement some kind of loop detection. If an implementation detects a loop or still sees a FILTER search-key after performing at least 3 substitutions, it MUST behave as if the specified filter doesn't exist (as described above).
名前のフィルタ自体がFILTER検索キーを使用して別のフィルタを参照できることに注意してください。実装は、少なくとも3置換はSEARCHコマンド基準に合格実行できる必要があります。実装は、より多くのパスを可能にした場合は、ループ検出のいくつかの種類を実装しなければなりません。実装は、ループを検出または静止少なくとも3つの置換を行った後、フィルタの検索キーを見れば、指定されたフィルタが存在しないかのように（上記のように）、それに動作しなければなりません。
Note that use of the FILTER search key implies the CHARSET "UTF-8" parameter to the SEARCH/UID SEARCH command. If the SEARCH/UID SEARCH command includes the explicit CHARSET parameter with the value other than "UTF-8" or "US-ASCII", then such command MUST result in the tagged BAD response from the server. Such tagged response MUST contain the BADCHARSET response code (see [RFC3501]).
FILTER検索キーの使用はSEARCH / UID SEARCHコマンドにCHARSET「UTF-8」パラメータを意味します注意してください。 SEARCH / UID SEARCHコマンドは「UTF-8」または「US-ASCII」以外の値で明示的なcharsetパラメータが含まれている場合、そのようなコマンドは、サーバからのタグ付きBAD応答をもたらさなければなりません。そのようなタグ付けされた応答は、（[RFC3501]を参照）BADCHARSET応答コードを含まなければなりません。
Any server compliant with this document MUST either implement the METADATA-SERVER (or METADATA) [METADATA] extension, or implement SETMETADATA/GETMETADATA commands described in [METADATA] so that they work for the case of empty mailbox name (i.e., for managing server annotations) and for the entries specified in this section.
この文書に準拠する任意のサーバーは、メタデータ-SERVER（またはメタデータ）[METADATA]拡張を実装するか、[METADATA]で説明SETMETADATA /のgetMetaDataコマンドを実装しなければならないのいずれか、彼らは、サーバーを管理するための、すなわち空のメールボックス名（の場合のために働くように、注釈）と、このセクションで指定されたエントリの。
This document reserves two hierarchies of per-server entries under the "/private/filters/values" and "/shared/filters/values" roots (see [METADATA]) for storing filter values. The value of a "/private/ filters/values/<filter_name>" or a "/shared/filters/values/ <filter_name>" server annotation is an IMAP SEARCH criteria, conforming to ABNF for the "search-criteria" non-terminal. A name of a filter is governed by the ABNF for the "filter-name" non-terminal.
「/プライベート/フィルター/値」と「/共有/フィルター/値」の根の下でこのドキュメントの埋蔵ごとのサーバーのエントリの2つの階層には、フィルタ値を格納する（[METADATA]を参照します）。 「/プライベート/フィルター/値/ <FILTER_NAME>」または「/共有/フィルター/値/ <FILTER_NAME>」サーバーアノテーションは、「検索条件」のためのABNFに準拠し、IMAPの検索条件で非の値ターミナル。フィルタの名前は、「フィルタ名」以外の端末についてABNFによって支配されています。
Note that values of all search keys stored in these entries MUST be encoded in UTF-8.
これらのエントリに記憶されている全ての検索キーの値は、UTF-8でエンコードされなければならないことに留意されたいです。
A new filter named "<filter_name>" can be created (or an existing filter can be modified) by storing a non-NIL value in the "/private/ filters/values/<filter_name>" server entry (or in the "/shared/ filters/values/<filter_name>") using the SETMETADATA [METADATA] command. The server SHOULD verify that each search criterion stored in such a server entry is a full and correct search criterion.
「/プライベート/フィルター/値/ <FILTER_NAME>」サーバ・エントリ（または「/中に非NIL値を格納することにより、「<FILTER_NAME>」を作成することができます（または既存のフィルタを変更することができる）という名前の新しいフィルタ共有/フィルタ/値/ <FILTER_NAME>」）SETMETADATA [METADATA]コマンドを使用して。サーバは、サーバのエントリに格納された各検索基準は完全かつ正確な検索条件であることを確認してください。
A filter can be deleted by storing the NIL value in both the "/private/filters/values/<filter_name>" and the "/shared/filters/ values/<filter_name>" entries.
フィルタは「/プライベート/フィルタ/値/ <FILTER_NAME>」と「/共有/フィルタ/値/ <FILTER_NAME>」エントリの両方でNIL値を格納することによって削除することができます。
A filter can be renamed by first creating a filter with the new name (that has the same value as the old one) and then deleting the filter with the old one.
フィルタは、第1（古いものと同じ値を持つ）新しい名前でフィルタを作成し、古いものとフィルタを削除することにより、名前を変更することができます。
If both "/private/filters/values/<filter_name>" and "/shared/filters/ values/<filter_name>" server annotations exist, then the value of the "/private/filters/values/<filter_name>" is used when evaluating the corresponding FILTER SEARCH key (see Section 3.1). Otherwise the non-NIL (existent) value is used.
「/プライベート/フィルター/値/ <FILTER_NAME>」使用されているのであれば、両方の「/プライベート/フィルター/値/ <FILTER_NAME>」および「/共有/フィルター/値/ <FILTER_NAME>」サーバーの注釈が存在し、その値対応するフィルタの検索キーを評価するとき（3.1節を参照してください）。それ以外の場合は非NIL（存在しない）値が使用されます。
If the server is unable to create a new typed filter because the maximum number of allowed filters has already been reached, the server MUST return a tagged NO response with a "[METADATA TOOMANY]" response code, as defined in [METADATA].
許可フィルタの最大数はすでに達しているため、サーバーは新しい型指定されたフィルタを作成することができない場合、サーバは[METADATA]で定義されている「[METADATA TOOMANY]」応答コードでタグ付きNO応答を返してはなりません。
C: a007 SETMETADATA "" ("/private/filters/values/on-the-road"
"OR SMALLER 5000 FROM \"boss@example.com\"")
S: a007 OK SETMETADATA complete
Client implementation note: As multiple clients might read and write filter values, it is possible that one client will use a SEARCH key that might not be recognized by another client that tries to present a user interface for editing a filter value. In order to help other clients to (partially) parse filter values for editing purposes, a client storing a filter value SHOULD use () around any SEARCH key not defined in [RFC3501]. For example, if there is an IMAP extension that defines a new x-dsfa SEARCH key that takes 2 parameters, then the following SEARCH criterion 'from "@example.com>" x-dsfa from 5' should be stored as 'from "@example.com>" (x-dsfa from 5)'.
クライアントの実装上の注意：複数のクライアントがフィルタ値を読み書きかもしれませんが、1つのクライアントがフィルタ値を編集するためのユーザインタフェースを提示しようとする別のクライアントによって認識されない可能性があります検索キーを使用することも可能です。 （部分的に）編集のためにフィルタ値を解析するために、他のクライアントを支援するために、[RFC3501]で定義されていない任意の検索キーの周りに（）を使用する必要があり、フィルタ値を記憶するクライアント。例えば、「"からとして格納されるべきである5「から『@ example.com>』X-dsfaから」次に2つのパラメータは、次の検索基準を取る新しいx dsfa検索キーを定義IMAP拡張がある場合@ example.com>」（5からX-dsfa「）。
Note that filter names are restricted to a subset of US-ASCII, as described in Section 4. So they might not always be meaningful to users and thus not necessarily suitable for display purposes. In order to help with storing human-readable descriptions of filters, this document also reserves two hierarchies of server entries under the "/private/filters/descriptions" and "/shared/filters/ descriptions" roots. The value of a "/private/filters/descriptions/ <filter_name>" or a "/shared/filters/descriptions/<filter_name>" server annotation is a human-readable description for the <filter_name> filter, encoded in UTF-8 [UTF-8]. If the "/private/ filters/descriptions/<filter_name>" server annotation exists, its value is used by the client as the filter description. Otherwise, the value of the "/shared/filters/descriptions/<filter_name>" server annotation is used as the filter description. In the absence of both the "/private/filters/descriptions/<filter_name>" and the "/shared/ filters/descriptions/<filter_name>" entries, the client MAY display the name of the filter as its description.
だから、彼らは常にユーザーには意味がないかもしれません第4節で説明すると、表示用のため、必ずしも適切ではないとして、フィルタ名は、US-ASCIIのサブセットに制限されていることに注意してください。フィルタの人間が読める記述を格納を支援するために、この文書はまた、「/プライベート/フィルター/説明」と「/共有/フィルター/説明」根の下で、サーバ・エントリの2つの階層を留保します。 「/プライベート/フィルター/説明/ <FILTER_NAME>」の値や「/共有/フィルター/説明/ <FILTER_NAME>」サーバーアノテーションがUTF-8でエンコードされ、<FILTER_NAME>フィルタの人間が読める記述です[UTF-8]。 「/プライベート/フィルター/説明/ <FILTER_NAME>」サーバーの注釈が存在する場合は、その値は、フィルタの説明など、クライアントによって使用されます。それ以外の場合は、「/共有/フィルター/説明/ <FILTER_NAME>」サーバーの注釈の値は、フィルタの説明として使用されています。両方の「/プライベート/フィルター/説明/ <FILTER_NAME>」および「/共有/フィルター/説明/ <FILTER_NAME>」エントリが存在しない場合には、クライアントは、その説明として、フィルタの名前を表示することがあります。
The description string SHOULD be annotated with one or more language tags [RFC4646] as specified in Chapter 16.9 of [Unicode]. In the absence of any language tag, the "i-default" [RFC2277] language SHOULD be assumed. Description in multiple languages MAY be present in a single description string. This is done by concatenating descriptions in multiple languages into a single string, each description prefixed with its language tag, for example "<ru><...description in Russian...><fr-ca><...description in French...>". Note that here <ru> is a language tag consisting of 3 Unicode characters: <U+E0001>, <U+E0072>, <U+E0075>; and <fr-ca> is a language tag consisting of 6 Unicode characters: <U+E0001>, <U+E0066>, <U+E0072>, <U+E002D>, <U+E0063>, <U+E0061>.
説明文字列は、[ユニコード]の章16.9で指定されたように、1個のまたは複数の言語タグ[RFC4646]で注釈されるべきです。任意の言語タグの非存在下で、「I-デフォルト」[RFC2277]言語が想定されるべきです。複数の言語での説明は、単一の記述文字列中に存在してもよいです。これは、<...ロシア...で記述> <FR-CA> <...説明では、<RU>」とは、例えば、単一の文字列、その言語タグが付い各記述の中に複数の言語で記述を連結することにより行われますフランス語...>」。ここで<RUが> 3つのUnicode文字から成る言語タグであることに注意してください、<U + E0072>、<U + E0001> <U + E0075>。そして<FR-CA> 6つのUnicode文字から成る言語タグである<U + E0001>、<U + E0066>、<U + E0072>、<U + E002D>、<U + E0063>、<U + E0061 >。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は、[ABNF]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。
Non-terminals referenced but not defined below are as defined by [RFC3501] or [IMAPABNF].
[RFC3501]または[IMAPABNF]によって定義されるような非末端参照が、以下に定義されていないです。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
capability =/ "FILTERS"
機能= / "FILTERS"
search-criteria = search-key *(SP search-key)
検索条件=検索キー*（SP-検索キー）
search-key =/ "FILTER" SP filter-name ;; New SEARCH criterion for referencing filters
検索キー= / "FILTER" SPフィルタ名;;フィルタを参照するための新しい検索基準
filter-name = 1*<any ATOM-CHAR except "/"> ;; Note that filter-name disallows UTF-8 or ;; the following characters: "(", ")", "{", ;; " ", "%", "*", "]". See definition of ;; ATOM-CHAR [RFC3501].
フィルタ名= 1 * <以外の任意のATOM-CHAR "/"> ;;そのフィルタ名がUTF-8許可しませんか注意してください;;次の文字 "（"、 "）"、 "{"、;; ""、 "％"、 "*"、 "]"。定義を参照してください;; ATOM-CHAR [RFC3501]。
resp-text-code =/ "UNDEFINED-FILTER" SP filter-name
RESP-テキストコード= / "UNDEFINED-FILTER" SPフィルタ名
General issues relevant to [RFC3501] (in particular to the SEARCH command) and METADATA-SERVER extension [METADATA] are also relevant to this document.
[RFC3501]（SEARCHコマンドに特に）とメタデータ-SERVER拡張子[METADATA]に関連する一般的な問題も、このドキュメントに関連しています。
Note that excessive use of filters can potentially simplify denial-of-service attacks, especially if combined with poor implementations and lack of loop detection (i.e., detection of filters referencing each other to create a loop). Servers that allow for anonymous access SHOULD NOT allow anonymous users to create/edit/delete filters.
フィルタの過度の使用は、潜在的に貧弱な実装及びループ検出の欠如と組み合わせる場合は特に、サービス拒否攻撃を簡略化することができることに留意されたい（すなわち、フィルタの検出ループを作成するために、お互いを参照）。匿名アクセスを許可サーバーは、匿名ユーザーがフィルタを削除/編集/作成するために許してはなりません。
Also note that stored filters can potentially disclose personal information about users. When confidentiality of such information is important, clients MUST use TLS and/or SASL security layer (or similar) as recommended in [RFC3501]. Also, clients should use
また、保存されたフィルタは、潜在的利用者に関する個人情報を開示できることに注意してください。そのような情報の機密性が重要である場合、[RFC3501]に推奨されているように、クライアントは、TLSおよび/またはSASLセキュリティ層（または類似の）を使用する必要があります。また、クライアントが使用する必要があります
private filters instead of public, unless they desire to share such information with other users.
プライベートフィルタの代わりに、パブリック、彼らは他のユーザーと、そのような情報を共有することを望む場合を除きます。
As always, it is important to thoroughly test clients and servers when implementing this extension.
この拡張機能を実装するときにいつものように、徹底的にクライアントとサーバをテストすることが重要です。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The IMAP4 capabilities registry is available from http://www.iana.org.
IMAP4機能は標準化過程かIESGが承認した実験的RFCを公開することにより、登録されています。 IMAP4機能レジストリはhttp://www.iana.orgから入手可能です。
This document defines the FILTERS IMAP capability. IANA has added it to the registry.
この文書では、FILTERSのIMAP機能を定義します。 IANAは、レジストリに追加しました。
IANA has added the following 4 entries to the [METADATA] registry:
IANAは、[METADATA]レジストリに以下の4つのエントリを追加しました。
To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: Server Name: /private/filters/values/<filter_name> Description: Contains an IMAP SEARCH criteria. Defined in RFC 5466. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov Email: alexey.melnikov@isode.com
To：iana@iana.org件名：IMAPメタデータエントリ登録の種類：サーバー名：/プライベート/フィルター/値/ <FILTER_NAME>説明：IMAPの検索条件が含まれています。 RFC 5466.コンテンツタイプに定義されている：text / plainで、文字セット= UTF-8担当者：アレクセイ・メルニコフEメール：alexey.melnikov@isode.com
To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: Server Name: /shared/filters/values/<filter_name> Description: Contains an IMAP SEARCH criterion. Defined in RFC 5466. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov Email: alexey.melnikov@isode.com
To：iana@iana.org件名：IMAPメタデータエントリ登録タイプ：サーバー名：/共有/フィルター/値/ <FILTER_NAME>説明：IMAP検索条件が含まれています。 RFC 5466.コンテンツタイプに定義されている：text / plainで、文字セット= UTF-8担当者：アレクセイ・メルニコフEメール：alexey.melnikov@isode.com
To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: Server Name: /private/filters/descriptions/<filter_name> Description: Contains a user-specific human-readable description of a named SEARCH criterion stored in the /private/filters/values/ <filter_name> or /shared/filters/values/<filter_name> annotation. The value is in UTF-8. Defined in RFC 5466. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov Email: alexey.melnikov@isode.com
To：iana@iana.org件名：IMAPメタデータエントリ登録の種類：サーバー名：/プライベート/フィルター/説明/ <FILTER_NAME>説明：/ /プライベートに保存されている名前の検索基準のユーザー固有の人間が読める記述が含まれていますフィルタ/値/ <FILTER_NAME>または/共有/フィルター/値/ <FILTER_NAME>注釈。値はUTF-8です。 RFC 5466.コンテンツタイプに定義されている：text / plainで、文字セット= UTF-8担当者：アレクセイ・メルニコフEメール：alexey.melnikov@isode.com
To: iana@iana.org Subject: IMAP METADATA Entry Registration Type: Server Name: /shared/filters/descriptions/<filter_name> Description: Contains a global (shared among all users) human-readable description of a named SEARCH criterion stored in the /private/filters/values/<filter_name> or /shared/filters/values/ <filter_name> annotation. The value is in UTF-8. Defined in RFC 5466. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov Email: alexey.melnikov@isode.com
To：件名iana@iana.org：IMAPメタデータエントリ登録タイプ：サーバ名：/共有/フィルター/説明/ <FILTER_NAME>説明：に保存されている名前の検索基準のグローバル（すべてのユーザー間で共有）人間が読める記述が含まれています/プライベート/フィルター/値/ <FILTER_NAME>または/共有/フィルター/値/ <FILTER_NAME>注釈。値はUTF-8です。 RFC 5466.コンテンツタイプに定義されている：text / plainで、文字セット= UTF-8担当者：アレクセイ・メルニコフEメール：alexey.melnikov@isode.com
Thanks to David Cridland, Arnt Gulbrandsen, Chris Newman, and Timo Sirainen for comments and suggestions on this document. Special thank you to Brian E. Carpenter for the GenArt review.
このドキュメントに関するコメントや提案のためのデビッドCridland、ARNT Gulbrandsenの、クリス・ニューマン、そしてティモ・シレーヌンに感謝します。特別GenArtレビューのためにブライアンE.カーペンターをお願い致します。
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]クロッカー、D.、エド。そして、P. Overell、エド、 "構文仕様のための増大しているBNF：ABNF"。、STD 68、RFC 5234、2008年1月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF]メルニコフ、A.およびC. Dabooは、RFC 4466、2006年4月 "IMAP4 ABNFへの拡張を集めました"。
[METADATA] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[メタデータ] Daboo、C.、 "IMAPメタデータの拡張"、RFC 5464、2009年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、BCP 47、RFC 4646、2006年9月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[Unicode] "The Unicode Standard 5.0", Unicode 5.0, 2007, <http://www.unicode.org/versions/Unicode5.0.0/>.
[UNICODE] "Unicode規格5.0"、ユニコード5.0、2007年<http://www.unicode.org/versions/Unicode5.0.0/>。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
カーティスキングISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Curtis.King@isode.com
メールアドレス：Curtis.King@isode.com