[要約] RFC 5466は、IMAP4プロトコルにおける名前付き検索（フィルタ）の拡張を定義しています。このRFCの目的は、クライアントがサーバーに対して特定の検索条件を名前で指定できるようにすることです。
Network Working Group A. Melnikov
Request for Comments: 5466 C. King
Category: Standards Track Isode Ltd
February 2009
IMAP4 Extension for Named Searches (Filters)
名前付き検索の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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
フィルターIMAP拡張機能は、永続的な名前の検索（別名「フィルター」）を参照するための新しいフィルター検索基準を追加し、そのようなフィルターをリスト/作成/削除するためにGetMetadata/SetMetadataコマンド[メタデータ]を再利用します。
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.
フィルター名のペアとフィルタータイプA「タイプフィルター」を呼び出します。各型型フィルターには、値（「検索基準」非ターミナルの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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Basic familiarity with the METADATA-SERVER extension [METADATA] and terms defined therein is required to understand this document.
このドキュメントを理解するには、メタデータサーバー拡張[メタデータ]およびそこで定義されている用語に対する基本的な精通度が必要です。
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拡張は、「フィルター」を機能する機能または応答コードのサポートされている機能の1つとして宣伝する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.
検索コマンドのフィルター基準により、クライアントはサーバーに保存されているフィルターを名前で参照できます。このようなフィルターは、「/private/filters/values/<filter_name>」という名前のサーバーアノテーションを設定することで作成されました（またはサーバーアノテーション "/shared/filters/values/<filter_name>"、 "/private/filters/values/<filter_name> "存在しません）セクション3.2で説明されているように、setmetadataコマンドを使用します。
Syntax: 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
名前付きフィルターが存在すると、その検索基準（つまり、関連するエントリ値）がフィルター検索キーの代わりに逐語的に挿入されます。たとえば、次の検索コマンド
C: a SEARCH UID 300:900 FILTER on-the-road SINCE "3-Dec-2002"
C：「2002年12月3日」以来、路上での検索UID 300：900フィルター
would be equivalent to the following
以下に相当します
C: a SEARCH UID 300:900 OR SMALLER 5000 FROM "boss@example.com" SINCE "3-Dec-2002"
C：「boss@example.com」からの検索UID 300：900またはSmall 5000または「2002年3月3日」以降
assuming the filter "on-the-road" exists and contains the value 'OR SMALLER 5000 FROM "boss@example.com"'.
「オンロード」が存在し、「boss@example.com」からの値または小さい5000を含むフィルターが存在すると仮定します。
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.
存在しないまたはアクセス不可能な（たとえば、アクセス制御制限による）フィルターへの参照は、未定義のフィルター応答コードを含むタグ付きNO応答と、その後に存在しない/アクセス不可能なフィルターの名前を含むタグ付きNO応答を使用して、検索コマンドの障害を引き起こす必要があります。
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.
注サーバーは、フィルター検索キーによって参照される各検索基準が完全かつ正しい検索基準であることを確認する必要があります。たとえば、この値には1つのパラメーターが欠けているため、完全に指定された検索条件ではないため、検索基準が「または小さい」検索基準を含むフィルターを参照する場合、サーバーは検索コマンドに障害を失敗させる必要があります。
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).
名前付きフィルター自体は、フィルター検索キーを使用して別のフィルターを参照できることに注意してください。実装は、検索コマンド基準で少なくとも3つの置換パスを実行できる必要があります。実装でより多くのパスを可能にする場合、何らかのループ検出を実装する必要があります。実装がループを検出するか、少なくとも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]).
フィルター検索キーを使用すると、検索/UID検索コマンドへのCharset "UTF-8"パラメーターが示されることに注意してください。検索/UID検索コマンドに、「UTF-8」または「US-ASCII」以外の値を持つ明示的なcharsetパラメーターが含まれている場合、そのようなコマンドはサーバーからのタグ付き悪い応答になる必要があります。このようなタグ付けされた応答には、BadCharset応答コードが含まれている必要があります（[RFC3501]を参照）。
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.
このドキュメントに準拠したサーバーは、メタデータサーバー（またはメタデータ）[メタデータ]拡張機能を実装するか、[メタデータ]で説明されている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.
このドキュメントは、フィルター値を保存するために「/private/filters/values」および「/shared/filters/values」ルート（[メタデータ]を参照）の「/private/filters/values」および「/shared/filters/values」ルートの下で、サーバーごとのエントリの2つの階層を留保します。"/private/filters/values/<filter_name>"または "/shared/filters/values/<filter_name>"サーバーアノテーションの値はIMAP検索条件であり、「検索基準」以外のABNFに準拠しています。ターミナル。フィルターの名前は、「フィルター名」非末端の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>」という名前の新しいフィルターを作成できます（または既存のフィルターを変更できます）。setmetadata [metadata]コマンドを使用して、shared/filters/values/<filter_name> "）。サーバーは、このようなサーバーエントリに保存されている各検索基準が完全かつ正しい検索基準であることを確認する必要があります。
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.
フィルターは、 "/private/filters/values/<filter_name>"と "/shared/filters/values/<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.
フィルターは、最初に新しい名前（古い名前と同じ値を持つ）を使用したフィルターを作成し、古いフィルターで削除することで名前が変更できます。
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.
"/private/filters/values/<filter_name>"と "/shared/filters/values/<filter_name>"サーバーアノテーションの両方が存在する場合、「/private/filters/values/<filter_name>」の値が使用されます対応するフィルター検索キーを評価する場合（セクション3.1を参照）。それ以外の場合は、非ニル（既存の）値が使用されます。
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].
[メタデータ]で定義されているように、サーバーが許可されたフィルターの最大数に既に到達しているために新しいタイプフィルターを作成できない場合、サーバーは「[メタデータトーマニー]」応答コードでタグ付けされた応答を返す必要があります。
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)'.
クライアントの実装注：複数のクライアントがフィルター値を読み書きする可能性があるため、あるクライアントは、フィルター値を編集するためにユーザーインターフェイスを提示しようとする別のクライアントが認識されない検索キーを使用する可能性があります。他のクライアントが編集目的で（部分的に）フィルター値を解析するのを支援するために、[RFC3501]で定義されていない検索キーの周りにフィルター値を保存するクライアントが使用する必要があります。たとえば、2つのパラメーターを取得する新しいX-DSFA検索キーを定義するIMAP拡張機能がある場合、次の検索基準「@example.com>」からのX-DSFAから5 'から「from」として保存する必要があります。@example.com> "（x-dsfa from 5） '。
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つの階層を留保します。"/private/filters/districtions/<filter_name>"または "/shared/filters/descriptions/<filter_name>"サーバーアノテーションの値は、UTF-8でエンコードされた<filter_name>フィルターの人間の読み取り可能な説明です[UTF-8]。「/プライベート/フィルター/説明/<filter_name>」サーバーアノットが存在する場合、その値はフィルターの説明としてクライアントによって使用されます。それ以外の場合、「/shared/filters/descriptions/<filter_name>」サーバーアノテーションの値は、フィルターの説明として使用されます。"/private/filters/descriptions/<filter_name>"と "/shared/filters/descriptions/<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>.
[unicode]の第16.9章で指定されているように、説明文字列には1つ以上の言語タグ[RFC4646]で注釈を付ける必要があります。言語タグがない場合、「i-default」[RFC2277]言語を想定する必要があります。複数の言語の説明は、単一の説明文字列に存在する場合があります。これは、複数の言語の説明を単一の文字列に連結することによって行われます。たとえば、その言語タグが付いた各説明、たとえばロシア語の説明...> <fr-ca> <...説明の説明フランス語...> "。ここでは、<ru>は3つのUnicode文字で構成される言語タグです。<fr-ca>は、6つのユニコード文字（<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]で指定されているように、拡張されたBackus-Naurフォーム（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"
search-criteria = search-key *(SP search-key)
検索基準= search-key *（sp search-key）
search-key =/ "FILTER" SP filter-name
;; New SEARCH criterion for referencing filters
filter-name = 1*<any ATOM-CHAR except "/">
;; Note that filter-name disallows UTF-8 or
;; the following characters: "(", ")", "{",
;; " ", "%", "*", "]". See definition of
;; ATOM-CHAR [RFC3501].
resp-text-code =/ "UNDEFINED-FILTER" SP filter-name
General issues relevant to [RFC3501] (in particular to the SEARCH command) and METADATA-SERVER extension [METADATA] are also relevant to this document.
[RFC3501]に関連する一般的な問題（特に検索コマンドに）およびメタデータサーバー拡張[メタデータ]もこのドキュメントに関連しています。
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 private filters instead of public, unless they desire to share such information with other users.
また、保存されたフィルターは、ユーザーに関する個人情報を潜在的に開示できる可能性があることに注意してください。そのような情報の機密性が重要な場合、クライアントは[RFC3501]で推奨されているように、TLSおよび/またはSASLセキュリティレイヤー（または同様）を使用する必要があります。また、クライアントは、そのような情報を他のユーザーと共有したい場合を除き、公開の代わりにプライベートフィルターを使用する必要があります。
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.
このドキュメントは、フィルターIMAP機能を定義しています。IANAはそれをレジストリに追加しました。
IANA has added the following 4 entries to the [METADATA] registry:
IANAは、[メタデータ]レジストリに次の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
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
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
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
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.
David Cridland、Arnt Gulbrandsen、Chris Newman、Timo Sirainenに感謝します。GenArt Reviewについては、Brian E. Carpenterに特別に感謝します。
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D.、ed。and P. Overell、ed。、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[Imapabnf] Melnikov、A。and C. daboo、「拡張機能をIMAP4 ABNFに収集しました」、RFC 4466、2006年4月。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、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 Standard 5.0"、Unicode 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
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Curtis.King@isode.com