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 ( 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ドキュメント(ライセンス情報)に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。



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
1. Introduction and Overview

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.


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.


2. Conventions Used in This Document

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.


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.


3. IMAP Protocol Changes
3. IMAPプロトコルの変更

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.


3.1. FILTER SEARCH Criterion
3.1. FILTER検索条件

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>


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:検索UID 300:900 FILTER路上 "3 - 12月-2002" SINCE

would be equivalent to the following


C: a SEARCH UID 300:900 OR SMALLER 5000 FROM "" SINCE "3-Dec-2002"

C:検索UID 300:900 OR "3-12月-2002" SINCE "" FROM 5000 SMALLER

assuming the filter "on-the-road" exists and contains the value 'OR SMALLER 5000 FROM ""'.

「オン・ザ・ロード」フィルタを想定して存在し、値「OR 『』 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.


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.


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).


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応答コードを含まなければなりません。

3.2. Managing Filters Using SETMETADATA/GETMETADATA Commands
3.2. SETMETADATA /のgetMetaDataコマンドを使用してフィルタの管理

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.


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.


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 \"\"")
           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 ">" x-dsfa from 5' should be stored as 'from ">" (x-dsfa from 5)'.

クライアントの実装上の注意:複数のクライアントがフィルタ値を読み書きかもしれませんが、1つのクライアントがフィルタ値を編集するためのユーザインタフェースを提示しようとする別のクライアントによって認識されない可能性があります検索キーを使用することも可能です。 (部分的に)編集のためにフィルタ値を解析するために、他のクライアントを支援するために、[RFC3501]で定義されていない任意の検索キーの周りに()を使用する必要があり、フィルタ値を記憶するクライアント。例えば、「"からとして格納されるべきである5「から『@>』X-dsfaから」次に2つのパラメータは、次の検索基準を取る新しいx dsfa検索キーを定義IMAP拡張がある場合@>」(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 >。

4. Formal Syntax

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].


Non-terminals referenced but not defined below are as defined by [RFC3501] or [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)


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フィルタ名

5. Security Considerations

General issues relevant to [RFC3501] (in particular to the SEARCH command) and METADATA-SERVER extension [METADATA] are also relevant to this document.


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.


As always, it is important to thoroughly test clients and servers when implementing this extension.


6. IANA Considerations
6. IANAの考慮事項

IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The IMAP4 capabilities registry is available from

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:


To: 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:

To:iana@iana.org件名:IMAPメタデータエントリ登録の種類:サーバー名:/プライベート/フィルター/値/ <FILTER_NAME>説明:IMAPの検索条件が含まれています。 RFC 5466.コンテンツタイプに定義されている:text / plainで、文字セット= UTF-8担当者:アレクセイ・メルニコフEメール

To: 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:

To:iana@iana.org件名:IMAPメタデータエントリ登録タイプ:サーバー名:/共有/フィルター/値/ <FILTER_NAME>説明:IMAP検索条件が含まれています。 RFC 5466.コンテンツタイプに定義されている:text / plainで、文字セット= UTF-8担当者:アレクセイ・メルニコフEメール

To: 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:

To:iana@iana.org件名:IMAPメタデータエントリ登録の種類:サーバー名:/プライベート/フィルター/説明/ <FILTER_NAME>説明:/ /プライベートに保存されている名前の検索基準のユーザー固有の人間が読める記述が含まれていますフィルタ/値/ <FILTER_NAME>または/共有/フィルター/値/ <FILTER_NAME>注釈。値はUTF-8です。 RFC 5466.コンテンツタイプに定義されている:text / plainで、文字セット= UTF-8担当者:アレクセイ・メルニコフEメール

To: 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:

To:件名メタデータエントリ登録タイプ:サーバ名:/共有/フィルター/説明/ <FILTER_NAME>説明:に保存されている名前の検索基準のグローバル(すべてのユーザー間で共有)人間が読める記述が含まれています/プライベート/フィルター/値/ <FILTER_NAME>または/共有/フィルター/値/ <FILTER_NAME>注釈。値はUTF-8です。 RFC 5466.コンテンツタイプに定義されている:text / plainで、文字セット= UTF-8担当者:アレクセイ・メルニコフEメール

7. Acknowledgments

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.カーペンターをお願い致します。

8. Normative References

[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, <>.

[UNICODE] "Unicode規格5.0"、ユニコード5.0、2007年<>。

Authors' Addresses


Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK

アレクセイ・メルニコフISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国



Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK

カーティスキングISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国