Internet Engineering Task Force (IETF)                     B. Leiba, Ed.
Request for Comments: 8457                           Huawei Technologies
Category: Standards Track                                 September 2018
ISSN: 2070-1721

IMAP "$Important" Keyword and "\Important" Special-Use Attribute

IMAPの「$ Important」キーワードと「\ Important」特殊用途属性



RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788.

RFC 6154はIMAP特殊用途LIST拡張を作成し、属性の初期セットを定義しました。このドキュメントは、新しい属性「\ Important」を定義し、RFC 5258、3501、および6154で定義された属性を含むIMAPフォルダ属性の新しいIANAレジストリを確立します。このドキュメントは、新しいIMAPキーワード「$ Important」も定義します、それをRFC 5788で定義されているレジストリに登録します。

Status of This Memo


This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1.  Conventions Used in This Document . . . . . . . . . . . . .   3
   2.  Definition of the "$Important" Message Keyword  . . . . . . .   3
   3.  Definition of the 'Important' Mailbox Attribute . . . . . . .   3
   3.1.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . .   4
   3.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.2.1.  Example of a LIST Response  . . . . . . . . . . . . . . .   4
   3.2.2.  Examples of Creating a New Mailbox Using "\Important" . .   4
   4.  Implementation Notes  . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.1.  Registration of the "$Important" Keyword  . . . . . . . . .   6
   6.2.  Creation of the IMAP Mailbox Name Attributes Registry . . .   7
   6.2.1.  Instructions to the Designated Expert . . . . . . . . . .   8
   6.3.  Initial Entries for the IMAP Mailbox Name Attributes
         Registry  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.1.  Normative References  . . . . . . . . . . . . . . . . . . .  10
   7.2.  Informative References  . . . . . . . . . . . . . . . . . .  10
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11
1. Introduction
1. はじめに

The Internet Message Access Protocol (IMAP) specification [RFC3501] defines the use of message keywords, and an "IMAP Keywords" registry is created in [RFC5788]. [RFC6154] defines an extension to the IMAP LIST command for special-use mailboxes. The extension allows servers to provide extra information (attributes) about the purpose of a mailbox and defines an initial set of special-use attributes.

インターネットメッセージアクセスプロトコル(IMAP)仕様[RFC3501]は、メッセージキーワードの使用を定義しており、[IMAPキーワード]レジストリが[RFC5788]に作成されています。 [RFC6154]は、特殊用途のメールボックス用のIMAP LISTコマンドの拡張を定義しています。拡張機能により、サーバーはメールボックスの目的に関する追加情報(属性)を提供し、特殊用途の属性の初期セットを定義できます。

This document does the following:


o defines a new message keyword, "$Important", to apply to messages that are considered important for the user by some externally defined criteria;

o 外部で定義された基準によってユーザーにとって重要であると見なされるメッセージに適用する新しいメッセージキーワード「$ Important」を定義します。

o registers the "$Important" keyword in the "IMAP Keywords" registry;

o 「$ Important」キーワードを「IMAPキーワード」レジストリに登録します。

o defines a new special-use attribute, "\Important", to designate a mailbox that will hold messages that are considered important for the user by some externally defined criteria; and

o 外部で定義された基準によってユーザーにとって重要であると見なされるメッセージを保持するメールボックスを指定するために、新しい特殊用途属性「\ Important」を定義します。そして

o creates a registry for IMAP mailbox attributes and registers the new attribute and those defined in [RFC5258], [RFC3501], and [RFC6154].

o IMAPメールボックス属性のレジストリを作成し、新しい属性と、[RFC5258]、[RFC3501]、および[RFC6154]で定義されている属性を登録します。

1.1. Conventions Used in This Document
1.1. このドキュメントで使用される規則

In the examples used in this document, "C:" indicates lines sent by a client that is connected to a server, and "S:" indicates lines sent by the server to the client.


2. Definition of the "$Important" Message Keyword
2. 「$ Important」メッセージキーワードの定義

The "$Important" keyword is a signal that a message is likely important to the user. The keyword is generally expected to be set automatically by the system based on available signals (such as who the message is from, who else the message is addressed to, evaluation of the subject or content, or other heuristics). While the keyword also can be set by the user, that is not expected to be the primary usage.

「$ Important」キーワードは、メッセージがユーザーにとって重要である可能性が高いことを示すシグナルです。キーワードは通常、利用可能なシグナル(メッセージの送信者、メッセージの宛先、サブジェクトまたはコンテンツの評価、その他のヒューリスティックなど)に基づいてシステムによって自動的に設定されると予想されます。キーワードはユーザーが設定することもできますが、それが主な使用法となることは想定されていません。

This is distinct from the "\Flagged" system flag in two ways:

これは、「\ Flagged」システムフラグとは次の2つの点で異なります。

1. "$Important" carries a meaning of general importance, as opposed to follow-up or urgency. It is meant to be used for a form of triage, with "\Flagged" remaining as a designation of special attention, need for follow-up, or time sensitivity. In particular, the sense of "$Important" is that other messages that are "like this one" according to some server-applied heuristics will also be considered "$Important".

1. 「$重要」は、フォローアップや緊急性とは対照的に、一般的に重要な意味を持っています。これは、トリアージの形式で使用することを意図しており、「\ Flagged」は特別な注意、フォローアップの必要性、または時間依存性の指定として残ります。特に、「$ Important」の意味は、サーバーが適用したヒューリスティックによると、「このメッセージのような」他のメッセージも「$ Important」と見なされるということです。

2. The setting of "$Important" is expected to be based at least partly on heuristics (generally set automatically by the server), whereas "\Flagged" is only intended to be set by the user with some sort of "flag this message" or "put a star on this message" interface.

2. "$ Important"の設定は、少なくとも一部はヒューリスティック(通常はサーバーによって自動的に設定される)に基づいていることが予想されますが、 "\ Flagged"は、ユーザーが何らかの "フラグこのメッセージにフラグを付ける"または「このメッセージにスターを付ける」インターフェース。

3. Definition of the 'Important' Mailbox Attribute
3. 「重要な」メールボックス属性の定義

The "\Important" mailbox attribute is a signal that the mailbox contains messages that are likely important to the user. In an implementation that also supports the "$Important" keyword, this special use is likely to represent a virtual mailbox collecting messages (from other mailboxes) that are marked with the "$Important" keyword. In other implementations, the system might automatically put messages there based on the same sorts of heuristics that are noted for the "$Important" keyword (see Section 2). The distinctions between "\Important" and "\Flagged" for mailboxes are similar to those between "$Important" and "\Flagged" for messages.

「\ Important」メールボックス属性は、メールボックスにユーザーにとって重要である可能性が高いメッセージが含まれていることを示す信号です。 「$ Important」キーワードもサポートする実装では、この特別な使用は、「$ Important」キーワードでマークされた(他のメールボックスからの)メッセージを収集する仮想メールボックスを表す可能性があります。他の実装では、システムは、「$ Important」キーワード(セクション2を参照)で言及されているのと同じ種類のヒューリスティックに基づいて、メッセージを自動的にそこに書き込む場合があります。メールボックスの「\ Important」と「\ Flagged」の違いは、メッセージの「$ Important」と「\ Flagged」の違いと似ています。

3.1. Formal Syntax
3.1. 正式な構文

The following syntax specification adds to the one in Section 6 of [RFC6154] using Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Be sure to see the ABNF notes at the beginning of Section 9 of [RFC3501].

次の構文仕様は、[RFC5234]で説明されているように、拡張バッカスナウアフォーム(ABNF)を使用して[RFC6154]のセクション6の構文仕様に追加されます。 [RFC3501]のセクション9の冒頭にあるABNFの注記を必ずご覧ください。

use-attr =/ "\Important"

use-attr = / "\重要"

3.2. Examples
3.2. 例
3.2.1. Example of a LIST Response
3.2.1. LIST応答の例

In the following example, the mailbox called "Important Messages" is the one designated with the "\Important" attribute.

次の例では、「重要なメッセージ」というメールボックスは、「\ Important」属性で指定されたものです。

      C: t1 LIST "" "Imp*"
      S: * LIST (\HasNoChildren \Important) "/" "Important Messages"
      S: * LIST (\HasNoChildren) "/" "Imported Wine"
      S: t1 OK Success
3.2.2. Examples of Creating a New Mailbox Using "\Important"
3.2.2. 「\ Important」を使用して新しいメールボックスを作成する例

In the following example, the mailbox called "Important Messages" is created with the "\Important" attribute on a server that advertises the "CREATE-SPECIAL-USE" capability string.

次の例では、「Important Messages」というメールボックスが、「CREATE-SPECIAL-USE」機能文字列をアドバタイズするサーバー上に「\ Important」属性を使用して作成されます。

      C: t1 CREATE "Important Messages" (USE (\Important))
      S: t1 OK Mailbox created

The following example is similar to the previous one, but the server is not able to assign the "\Important" attribute to the new mailbox.

次の例は前の例と似ていますが、サーバーは "\ Important"属性を新しいメールボックスに割り当てることができません。

      C: t1 CREATE "Important Messages" (USE (\Important))
      S: t1 NO [USEATTR] An \Important mailbox already exists

The following example is similar to the previous one, but the server does not support this extension.


      C: t1 CREATE "Important Messages" (USE (\Important))
      S: t1 NO [USEATTR] Mailbox not created; unsupported use \Important

In both of the failure-mode examples, the "USEATTR" response code lets the client know that the problem is in the "USE" parameters. Note that the same response code is given in both cases, and the human-readable text is the only way to tell the difference. That text is not parsable by the client (it can only be logged and/or reported to the user).


4. Implementation Notes
4. 実装上の注意

This section is non-normative and is intended to describe the intended (and current as of this publication) usage of "$Important" in contrast with "\Flagged" on a message.

このセクションは非規範的であり、メッセージの "\ Flagged"とは対照的に、 "$ Important"の使用目的(およびこのドキュメントの現在)を説明することを目的としています。

On the server:


o "\Flagged" is set or cleared in response to an explicit command from the client.

o 「\ Flagged」は、クライアントからの明示的なコマンドに応じて設定またはクリアされます。

o "$Important" is set via a heuristic process performed by the server and usually involves analysis of header fields, what mailbox the message is filed in, perhaps message content, attachments, and such. It may then be set or cleared in response to an explicit command from the client, and the server may use that to adjust the heuristics in the future. It's also possible that the server will re-evaluate this and make a message "$Important" later if the user accesses the message frequently, for example.

o "$ Important"はサーバーによって実行されるヒューリスティックプロセスによって設定され、通常はヘッダーフィールド、メッセージがどのメールボックスにファイルされているか、おそらくメッセージの内容、添付ファイルなどの分析を含みます。その後、クライアントからの明示的なコマンドに応じて設定またはクリアされ、サーバーはそれを使用して将来のヒューリスティックを調整します。たとえば、ユーザーが頻繁にメッセージにアクセスする場合、サーバーがこれを再評価し、後でメッセージ「$ Important」を作成する可能性もあります。

On the client:


o Typically, an icon such as a flag or a star (or an indication, such as red or bold text) is associated with "\Flagged", and the UI provides a way for the user to turn that icon or indication on or off. Manipulation of this results in a command to the server.

o 通常、フラグやスターなどのアイコン(または赤や太字のテキストなどの表示)は「\ Flagged」に関連付けられており、UIはユーザーがそのアイコンまたは表示をオンまたはオフにする方法を提供します。これを操作すると、サーバーにコマンドが送信されます。

o Typically, a lesser indication is used for "$Important". The client might or might not provide the user with a way to manipulate it. If it does, manipulation results in a command to the server.

o 通常、「$ Important」にはより少ない表示が使用されます。クライアントは、それを操作する方法をユーザーに提供する場合としない場合があります。存在する場合、操作によりサーバーへのコマンドが生成されます。

5. Security Considerations
5. セキュリティに関する考慮事項

The security considerations in Section 7 of [RFC6154] apply equally to this extension, in particular, "Conveying special-use information to a client exposes a small bit of extra information that could be of value to an attacker." Moreover, identifying important messages or a place where important messages are kept could give an attacker a strategic starting point. If the algorithm by which messages are determined to be important is well known, still more information is exposed -- perhaps, for example, there is an implication that the senders of these messages are particularly significant to the mailbox owner, and perhaps that is information that should not be made public.


As noted in RFC 6154, it is wise to protect the IMAP channel from passive eavesdropping and to defend against unauthorized discernment of the identity of a user's "\Important" mailbox or of a user's "$Important" messages. See Section 11 of [RFC3501] for security considerations about using the IMAP STARTTLS command to protect the IMAP channel.

RFC 6154に記載されているように、IMAPチャネルを受動的な盗聴から保護し、ユーザーの "\ Important"メールボックスまたはユーザーの "$ Important"メッセージのIDが不正に識別されないようにするのが賢明です。 IMAP STARTTLSコマンドを使用してIMAPチャネルを保護することに関するセキュリティの考慮事項については、[RFC3501]のセクション11を参照してください。

6. IANA Considerations
6. IANAに関する考慮事項

IANA has completed three actions, which are specified in the sections below:


1. registration of the "$Important" keyword;

1. 「$ Important」キーワードの登録。

2. creation of a new "IMAP Mailbox Name Attributes" registry; and

2. 新しい「IMAPメールボックス名属性」レジストリの作成。そして

3. registration of initial entries in the "IMAP Mailbox Name Attributes" registry.

3. "IMAP Mailbox Name Attributes"レジストリへの初期エントリの登録。

6.1. Registration of the "$Important" Keyword
6.1. 「$ Important」キーワードの登録

IANA has registered the "$Important" keyword in the "IMAP Keywords" registry, as follows, using the template in [RFC5788].


IMAP keyword name: $Important

IMAPキーワード名:$ Important

Purpose (description): The "$Important" keyword is a signal that a message is likely important to the user.

目的(説明):「$ Important」キーワードは、メッセージがユーザーにとって重要である可能性が高いことを示すシグナルです。

Private or Shared on a server: PRIVATE


Is it an advisory keyword or may it cause an automatic action: Advisory (but see the reference for details).


When/by whom the keyword is set/cleared: The keyword can be set by the user, or automatically by the system based on available signals (such as who the message is from, who else the message is addressed to, evaluation of the subject or content, or other heuristics).


Related keywords: None (see the reference for the related mailbox name attribute).


Related IMAP capabilities: None.


Security considerations: See Section 5 of RFC 8457.

セキュリティに関する考慮事項:RFC 8457のセクション5をご覧ください。

Published specification: RFC 8457 Person & email address to contact for further information: IETF Applications and Real-Time Area <>

公開された仕様:RFC 8457個人および電子メールアドレス(詳細については連絡先:IETFアプリケーションおよびリアルタイムエリア<>)

Intended usage: COMMON


Owner/Change controller: IESG


Note: None.


6.2. Creation of the IMAP Mailbox Name Attributes Registry
6.2. IMAPメールボックス名属性レジストリの作成

IANA has created a new registry in the group "Internet Message Access Protocol (IMAP)". It is called "IMAP Mailbox Name Attributes", and it has two references: "RFC 3501, Section 7.2.2", and "RFC 8457, Section 6". This registry will be shared with the JSON Meta Application Protocol (JMAP) for Mail [JMAP-MAIL].

IANAは、「インターネットメッセージアクセスプロトコル(IMAP)」グループに新しいレジストリを作成しました。これは「IMAPメールボックス名属性」と呼ばれ、「RFC 3501、セクション7.2.2」および「RFC 8457、セクション6」という2つの参照があります。このレジストリは、JSON Meta Application Protocol(JMAP)for Mail [JMAP-MAIL]と共有されます。

The registry entries contain the following fields:


1. Attribute Name 2. Description 3. Reference 4. Usage Notes

1. 属性名2.説明3.参照4.使用上の注意

IANA keeps this list in alphabetical order by Attribute Name, which is registered without the initial backslash ("\"). The names are generally registered with initial capital letters but are treated as case-insensitive US-ASCII strings.

IANAは、このリストを属性名のアルファベット順に保持します。属性名は、最初のバックスラッシュ( "\")なしで登録されます。名前は通常、最初の大文字で登録されますが、大文字と小文字を区別しないUS-ASCII文字列として扱われます。

The "Usage Notes" field is free-form US-ASCII text that will normally be empty (and is empty if it's not specified in the registration request). It is intended to hold things such as "not used by JMAP" and "JMAP only". The field is for human use, and there is no need for a registry of strings that may appear here.

「使用上の注意」フィールドは自由形式のUS-ASCIIテキストで、通常は空です(登録リクエストで指定されていない場合は空です)。 「JMAPでは使用しない」「JMAPのみ」などの保持を目的としています。このフィールドは人間が使用するためのものであり、ここに表示される文字列のレジストリは必要ありません。

The registration policy for the new registry is listed as "IETF Review" or "Expert Review" [RFC8126], and new registrations will be accepted in one of two ways:


1. For registrations requested in an IETF consensus document, the registration policy will be IETF Review, and the request will be made in the IANA Considerations section of the document, which gives the requested values for each of the fields.

1. IETFコンセンサスドキュメントでリクエストされた登録の場合、登録ポリシーはIETFレビューとなり、リクエストはドキュメントのIANAの考慮事項セクションで行われ、各フィールドにリクエストされた値が示されます。

2. For other registrations, the policy will be Expert Review policy (see Section 6.2.1), and the request will be made by sending email to IANA asking for a new IMAP Mailbox Name Attribute and giving the requested values for each of the fields. While a formal specification is not required, the reference document should provide a description of the proposed attribute sufficient for building interoperable implementations. An Informational RFC (submitted, for example, through the IETF or Independent stream) is a fine way to publish a reference document (see also Section 6.2.1).

2.その他の登録の場合、ポリシーはExpert Reviewポリシー(セクション6.2.1を参照)になり、新しいIMAPメールボックス名属性を要求する電子メールをIANAに送信し、各フィールドに要求された値を指定することによって要求が行われます。 。正式な仕様は必須ではありませんが、参照ドキュメントには、相互運用可能な実装を構築するのに十分な提案された属性の説明を提供する必要があります。情報RFC(たとえば、IETFまたは独立したストリームを通じて送信される)は、参照ドキュメントを公開するための優れた方法です(セクション6.2.1も参照)。

6.2.1. Instructions to the Designated Expert
6.2.1. 指定専門家への指示

The expert reviewer, who will be designated by the IESG, is expected to provide only a general review of the requested registration, checking that the reference and description are adequate for understanding the intent of the registered attribute. Efforts should also be made to generalize the intent of an attribute so that multiple implementations with the same requirements may reuse existing attributes. Except for this check, this is intended to be very close to a first come first served policy, and the expert should not block serious registration requests with a reasonable reference. The reference may be to any form of documentation, including a web page, but consideration should be given to providing one that is expected to be long-lived and stable.


6.3. Initial Entries for the IMAP Mailbox Name Attributes Registry
6.3. IMAPメールボックス名属性レジストリの初期エントリ

The registry initially contains these entries:


   | Attribute     | Description                       | Reference |
   | Name          |                                   |           |
   | All           | All messages                      | [RFC6154] |
   | Archive       | Archived messages                 | [RFC6154] |
   | Drafts        | Messages that are working drafts  | [RFC6154] |
   | Flagged       | Messages with the \Flagged flag   | [RFC6154] |
   | HasChildren   | Has accessible child mailboxes    | [RFC5258] | *
   | HasNoChildren | Has no accessible child mailboxes | [RFC5258] | *
   | Important     | Messages deemed important to user |  RFC 8457 |
   | Junk          | Messages identified as Spam/Junk  | [RFC6154] |
   | Marked        | Server has marked the mailbox as  | [RFC3501] | *
   |               | "interesting"                     |           |
   | NoInferiors   | No hierarchy under this name      | [RFC3501] | *
   | NonExistent   | The mailbox name doesn't actually | [RFC5258] | *
   |               | exist                             |           |
   | Noselect      | The mailbox is not selectable     | [RFC3501] | *
   | Remote        | The mailbox exists on a remote    | [RFC5258] | *
   |               | server                            |           |
   | Sent          | Sent mail                         | [RFC6154] |
   | Subscribed    | The mailbox is subscribed to      | [RFC5258] |
   | Trash         | Messages the user has discarded   | [RFC6154] |
   | Unmarked      | No new messages since last select | [RFC3501] | *

The rows marked with "*" at the end have their Usage Notes field set to "not used by JMAP".


7. References
7. 参考文献
7.1. Normative References
7.1. 引用文献

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <>.

[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF:ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<>。

[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, March 2011, <>.

[RFC6154] Leiba、B。およびJ. Nicolson、「IMAP LIST Extension for Special-Use Mailboxes」、RFC 6154、DOI 10.17487 / RFC6154、March 2011、< >。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https:// www / info / rfc8126>。

7.2. Informative References
7.2. 参考引用

[JMAP-MAIL] Jenkins, N. and C. Newman, "JMAP for Mail", Work in Progress, draft-ietf-jmap-mail-07, August 2018.

[JMAP-MAIL] Jenkins、N。およびC. Newman、「JMAP for Mail」、Work in Progress、draft-ietf-jmap-mail-07、2018年8月。

[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, DOI 10.17487/RFC5258, June 2008, <>.

[RFC5258] Leiba、B。およびA. Melnikov、「インターネットメッセージアクセスプロトコルバージョン4-LISTコマンド拡張」、RFC 5258、DOI 10.17487 / RFC5258、2008年6月、< / rfc5258>。

[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", RFC 5788, DOI 10.17487/RFC5788, March 2010, <>.

[RFC5788] Melnikov、A。およびD. Cridland、「IMAP4 Keyword Registry」、RFC 5788、DOI 10.17487 / RFC5788、2010年3月、<>。



The following author was an original contributor to this document in addition to the editor.


Eric "Iceman" Google Email:


Author's Address


Barry Leiba (editor) Huawei Technologies

バリー・レイバ(編集者)Huawei Technologies

   Phone: +1 646 827 0648