[要約] RFC 7888は、IMAP4プロトコルの非同期リテラルに関する仕様です。その目的は、IMAP4クライアントとサーバー間の通信を効率化し、リソースの使用を最小限に抑えることです。

Internet Engineering Task Force (IETF)                  A. Melnikov, Ed.
Request for Comments: 7888                                     Isode Ltd
Obsoletes: 2088                                                 May 2016
Category: Standards Track
ISSN: 2070-1721

IMAP4 Non-synchronizing Literals

IMAP4非同期リテラル

Abstract

概要

The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.

インターネットメッセージアクセスプロトコル（RFC 3501）には、文字列を通信するための「リテラル」構文構文が含まれています。クライアントからサーバーにリテラルを送信するとき、IMAPはクライアントに、サーバーがオクテットカウントと文字列データの送信の間にコマンド継続要求を送信するのを待つことを要求します。このドキュメントでは、このネットワークラウンドトリップを必要としないリテラルの代替形式を指定しています。

This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.

このドキュメントは2つのIMAP拡張を指定します：LITERAL +とLITERAL-。 LITERAL +は、すべてのIMAPコマンドでリテラルの代替形式を許可します。 LITERAL-はLITERAL +と同じですが、4096バイト以下でない限り、リテラルの代替形式を許可しません。

This document obsoletes RFC 2088.

このドキュメントはRFC 2088を廃止します。

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

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

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7888.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7888で入手できます。

Copyright Notice

著作権表示

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

Copyright（c）2016 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. 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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

目次 

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Considerations on When to Use and Not to Use Synchronizing
       Literals  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  LITERAL- Capability . . . . . . . . . . . . . . . . . . . . .   5
   6.  Interaction with BINARY Extension . . . . . . . . . . . . . .   6
   7.  Interaction with MULTIAPPEND Extension  . . . . . . . . . . .   6
   8.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Appendix A.  Changes since RFC 2088 . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9
1. Introduction
1. はじめに

The Internet Message Access Protocol [RFC3501] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.

インターネットメッセージアクセスプロトコル[RFC3501]には、文字列を通信するための「リテラル」構文構文が含まれています。クライアントからサーバーにリテラルを送信するとき、IMAPはクライアントに、サーバーがオクテットカウントと文字列データの送信の間にコマンド継続要求を送信するのを待つことを要求します。このドキュメントでは、このネットワークラウンドトリップを必要としないリテラルの代替形式を指定しています。

This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals (called "non-synchronized literals" below) in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.

このドキュメントは2つのIMAP拡張を指定します：LITERAL +とLITERAL-。 LITERAL +は、すべてのIMAPコマンドでリテラルの代替形式（以下「非同期リテラル」と呼ばれる）を許可します。 LITERAL-はLITERAL +と同じですが、4096バイト以下でない限り、リテラルの代替形式を許可しません。

2. Conventions
2. 規約

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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

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：」ラベルが複数の行に適用される場合、それらの行の間の改行は編集上の明確さのためだけであり、実際のプロトコル交換の一部ではありません。

3. Specification
3. 仕様

The non-synchronizing literal is added as an alternate form of literal, and it may appear in communication from client to server instead of the IMAP [RFC3501] form of literal. The IMAP form of literal, used in communication from client to server, is referred to as a synchronizing literal. The non-synchronizing literal form MUST NOT be sent from server to client.

非同期リテラルはリテラルの代替形式として追加され、IMAP [RFC3501]形式のリテラルではなく、クライアントからサーバーへの通信に表示される場合があります。クライアントからサーバーへの通信で使用されるIMAP形式のリテラルは、同期リテラルと呼ばれます。非同期リテラル形式は、サーバーからクライアントに送信してはなりません（MUST NOT）。

Non-synchronizing literals may be used with any IMAP server implementation that returns "LITERAL+" or "LITERAL-" as one of the supported capabilities to the CAPABILITY command. If the server does not advertise either of the above capabilities, the client can only use synchronizing literals. The difference between LITERAL+ and LITERAL- extensions is explained in Section 5.

非同期リテラルは、CAPABILITYコマンドでサポートされる機能の1つとして「LITERAL +」または「LITERAL-」を返す任意のIMAPサーバー実装で使用できます。サーバーが上記の機能のいずれも通知しない場合、クライアントは同期リテラルのみを使用できます。 LITERAL +拡張とLITERAL-拡張の違いについては、セクション5で説明します。

The non-synchronizing literal is distinguished from the original synchronizing literal by having a plus ('+') between the octet count and the closing brace ('}'). The server does not generate a command continuation request in response to a non-synchronizing literal, and clients are not required to wait before sending the octets of a non-synchronizing literal.

非同期リテラルは、オクテットカウントと右中かっこ（ '}'）の間にプラス（ '+'）を付けることにより、元の同期リテラルと区別されます。サーバーは、非同期リテラルに応答してコマンド継続要求を生成せず、クライアントは、非同期リテラルのオクテットを送信する前に待機する必要はありません。

The protocol receiver of an IMAP server MUST check the end of every received line (a sequence of octets that ends with a CRLF) for an open brace ('{') followed by an octet count, a plus ('+'), and a close brace ('}') immediately preceding the CRLF. This sequence (if found by the receiver) is the octet count of a non-synchronizing literal, and the server MUST treat the specified number of following octets and the following line (as defined in [RFC3501]) as part of the same command.

IMAPサーバーのプロトコルレシーバーは、受信されたすべての行の終わり（CRLFで終わるオクテットのシーケンス）をチェックして、括弧（ '{'）の後にオクテットカウント、プラス（ '+'）、 CRLFの直前の右中括弧（ '}'）。このシーケンス（受信者が見つけた場合）は、非同期リテラルのオクテットカウントであり、サーバーは、指定された数のオクテットと次の行（[RFC3501]で定義されている）を同じコマンドの一部として扱う必要があります。

It's important to note that the literal is not delimited by CRLF. It ends after the number of bytes specified by the octet count, and the current command continues from there. There might be a CRLF immediately after; it ends the command. Or, there might be more octets, specifying other command parameters, before the CRLF. If a SP (space) character is needed between parameters, it's important that the SP appear after the literal, in its appropriate place.

リテラルはCRLFで区切られていないことに注意することが重要です。オクテットカウントで指定されたバイト数の後に終了し、現在のコマンドはそこから続行されます。直後にCRLFが発生する可能性があります。コマンドを終了します。または、CRLFの前に、他のコマンドパラメータを指定するオクテットがさらに存在する場合があります。パラメータの間にSP（スペース）文字が必要な場合は、SPがリテラルの後ろの適切な場所にあることが重要です。

A server MAY still process commands and reject errors on a line-by-line basis, as long as it checks for non-synchronizing literals at the end of each line.

サーバーは、各行の終わりで非同期リテラルをチェックする限り、コマンドを処理し、行ごとにエラーを拒否できます（MAY）。

Example:

例： 

   C: A001 LOGIN {11+}
   C: FRED FOOBAR {7+}
   C: fat man
   S: A001 OK LOGIN completed

This is semantically equivalent to this version that uses quoted strings instead of literals:

これは、リテラルの代わりに引用符付きの文字列を使用するこのバージョンと意味的に同等です。 

   C: A001 LOGIN "FRED FOOBAR" "fat man"
   S: A001 OK LOGIN completed

Note that the space after FOOBAR in the first version corresponds to the space between the two quoted strings in the second.

最初のバージョンのFOOBARの後のスペースは、2番目のバージョンの2つの引用符付き文字列の間のスペースに対応することに注意してください。

4. Considerations on When to Use and Not to Use Synchronizing Literals
4. 同期リテラルを使用する場合と使用しない場合の考慮事項

Understanding of this section is important for both client and server developers of this IMAP extension.

このセクションの理解は、このIMAP拡張機能のクライアントとサーバーの両方の開発者にとって重要です。

While non-synchronizing literals have clear advantages for clients, such as simplicity of use, they might be more difficult to handle on the server side. When a client uses a non-synchronizing literal that is too big for the server to accept, a server implementation that is compliant with LITERAL+ has to make a choice between a couple non-optimal choices:

非同期リテラルは、使用が簡単なことなど、クライアントにとって明確な利点がありますが、サーバー側では処理が難しい場合があります。クライアントが、サーバーが受け入れるには大きすぎる非同期リテラルを使用する場合、LITERAL +に準拠するサーバー実装は、いくつかの最適ではない選択から選択する必要があります。

1. Read the number of bytes specified in the non-synchronizing literal and reject the command that included the literal anyway. (The server is allowed to send the tagged BAD/NO response before reading the whole non-synchronizing literal.) This is quite wasteful of bandwidth if the literal is large.

1. 非同期リテラルで指定されたバイト数を読み取り、とにかくリテラルを含むコマンドを拒否します。 （サーバーは、非同期リテラル全体を読み取る前に、タグ付けされたBAD / NO応答を送信できます。）これは、リテラルが大きい場合、帯域幅を無駄に消費します。

2. Send an untagged BYE response explaining the reason for rejecting the literal (possibly accompanied by an ALERT response code in another response) and close the connection. This will force the client to reconnect or report the error to the user. In the latter case, the error is unlikely to be understandable to the user. Additionally, some naive clients are known to blindly reconnect in this case and repeat the operation that caused the problem, introducing an infinite loop.

2. リテラルを拒否する理由を説明するタグなしのBYE応答を送信し（別の応答でALERT応答コードが付随している可能性があります）、接続を閉じます。これにより、クライアントは強制的に再接続するか、ユーザーにエラーを報告します。後者の場合、ユーザーがエラーを理解できない可能性があります。さらに、一部のナイーブクライアントは、この場合、盲目的に再接続し、問題の原因となった操作を繰り返して、無限ループを引き起こすことがわかっています。

The problem described above is most common when using the APPEND command, because most commands don't need to send lots of data from the client to the server. Some server implementations impose limits on literals (both synchronizing and non-synchronizing) accepted from clients in order to defend against denial-of-service attacks. Implementations can generally impose much lower limits on literal sizes for all commands other than APPEND. In order to address literal size issue in APPEND, this document introduces a new extension LITERAL-, described in Section 5.

ほとんどのコマンドはクライアントからサーバーに大量のデータを送信する必要がないため、上記の問題はAPPENDコマンドを使用する場合に最も一般的です。一部のサーバー実装では、サービス拒否攻撃を防ぐためにクライアントから受け入れられるリテラル（同期と非同期の両方）に制限を課しています。実装では一般に、APPEND以外のすべてのコマンドのリテラルサイズにはるかに低い制限を課すことができます。 APPENDでリテラルサイズの問題に対処するために、このドキュメントでは、セクション5で説明されている新しい拡張LITERAL-を紹介します。

The situation can also be improved by implementing support for the APPENDLIMIT extension [RFC7889], which allows a server to advertise its APPEND limit, so that well-behaved clients can check it and avoid uploading big messages in the first place.

APPENDLIMIT拡張[RFC7889]のサポートを実装することで状況を改善することもできます。これにより、サーバーがAPPEND制限をアドバタイズできるため、適切に動作するクライアントがそれをチェックして、最初に大きなメッセージをアップロードしないようにすることができます。

5. LITERAL- Capability
5. リテラル-機能

The LITERAL- extension is almost identical to LITERAL+, with one exception: when LITERAL- is advertised, non-synchronizing literals used in any command MUST NOT be larger than 4096 bytes. Any literal larger than 4096 bytes MUST be sent as a synchronizing literal as specified in RFC 3501. A server that is compliant with LITERAL- and encounters a non-synchronizing literal larger than 4096 bytes proceeds as described in Section 4. If responding to an APPEND command, the tagged BAD response MUST contain the TOOBIG response code [RFC4469]. If responding with an untagged BYE response, it SHOULD include the TOOBIG response code. Note that the form of the non-synchronizing literal does not change: it still uses the "+" in the literal itself, even if the applicable extension is LITERAL-.

LITERAL-拡張はLITERAL +とほぼ同じですが、1つの例外があります。LITERAL-がアドバタイズされる場合、コマンドで使用される非同期リテラルは4096バイトを超えてはなりません。 RFC 961で指定されているように、4096バイトを超えるリテラルは同期リテラルとして送信する必要があります。LITERAL-に準拠し、4096バイトを超える非同期リテラルに遭遇するサーバーは、セクション4で説明されているように処理を進めます。コマンド、タグ付けされたBAD応答には、TOOBIG応答コード[RFC4469]が含まれている必要があります。タグなしのBYE応答で応答する場合は、TOOBIG応答コードを含める必要があります。非同期リテラルの形式は変更されないことに注意してください。適用可能な拡張子がLITERAL-であっても、リテラル自体に「+」を使用します。

Because LITERAL- is a more restricted version of LITERAL+, IMAP servers MUST NOT advertise both of these capabilities at the same time. (A server implementation can choose to have a configuration option to indicate which one to advertise.)

LITERAL-はLITERAL +のより制限されたバージョンであるため、IMAPサーバーはこれらの機能の両方を同時にアドバタイズしてはなりません。 （サーバーの実装では、どのオプションを通知するかを示す構成オプションを選択できます。）

6. Interaction with BINARY Extension
6. BINARY拡張との相互作用

[RFC4466] updated the non-terminal "literal8" defined in [RFC3516] to allow for non-synchronizing literals if both BINARY [RFC3516] and LITERAL+ extensions are supported by the server.

[RFC4466]は、BINARY [RFC3516]とLITERAL +拡張の両方がサーバーでサポートされている場合に、非同期のリテラルを許可するように[RFC3516]で定義されている非ターミナル "literal8"を更新しました。

This document also allows use of this extended "literal8" syntax when both BINARY [RFC3516] and LITERAL- extensions are supported by the server.

このドキュメントでは、BINARY [RFC3516]とLITERAL-拡張の両方がサーバーでサポートされている場合に、この拡張「literal8」構文を使用することもできます。

7. Interaction with MULTIAPPEND Extension
7. MULTIAPPEND拡張機能との相互作用

[RFC3502] describes MULTIAPPEND extension and how it can be used with LITERAL+. The LITERAL- extension can be used with the MULTIAPPEND extension in the same way.

[RFC3502]は、MULTIAPPEND拡張機能と、LITERAL +でそれを使用する方法について説明しています。 LITERAL-拡張は、MULTIAPPEND拡張と同じ方法で使用できます。

8. Formal Syntax
8. 正式な構文

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

参照されているが以下で定義されていない非端末は、[RFC3501]で定義されているとおりです。 

     literal = "{" number ["+"] "}" CRLF *CHAR8
                ; Number represents the number of CHAR8 octets
        
     CHAR8   = <defined in RFC 3501>
        
     literal8 = <defined in RFC 4466>
9. Security Considerations
9. セキュリティに関する考慮事項

Use of non-synchronizing literals can consume extra resources (e.g. memory) on IMAP servers and can be used for denial-of-service attacks. The LITERAL- extension partially improved this situation.

非同期リテラルを使用すると、IMAPサーバーで余分なリソース（メモリなど）が消費され、サービス拒否攻撃に使用される可能性があります。 LITERAL-拡張は、この状況を部分的に改善しました。

This document doesn't raise any security concerns beyond those raised by [RFC3501].

このドキュメントは、[RFC3501]によって提起されたものを超えるセキュリティ上の懸念を提起しません。

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

IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The registry is currently located at <http://www.iana.org/assignments/imap-capabilities>.

IMAP4機能は、Standards TrackまたはIESG承認の実験的RFCを公開することによって登録されます。レジストリは現在<http://www.iana.org/assignments/imap-capabilities>にあります。

IANA has updated the above registry so that the reference for "LITERAL+" points to this document.

IANAは、「LITERAL +」の参照がこのドキュメントを指すように、上記のレジストリを更新しました。

IANA has added the "LITERAL-" capability to the above registry, with this document as the reference.

IANAは、このドキュメントを参照として、「LITERAL-」機能を上記のレジストリに追加しました。

11. References
11. 参考文献
11.1. Normative References
11.1. 引用文献

[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.

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

[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, DOI 10.17487/RFC3516, April 2003, <http://www.rfc-editor.org/info/rfc3516>.

[RFC3516] Nerenberg、L。、「IMAP4 Binary Content Extension」、RFC 3516、DOI 10.17487 / RFC3516、2003年4月、<http://www.rfc-editor.org/info/rfc3516>。

[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, <http://www.rfc-editor.org/info/rfc4466>.

[RFC4466] Melnikov、A。およびC. Daboo、「IMAP4 ABNFに対する収集された拡張機能」、RFC 4466、DOI 10.17487 / RFC4466、2006年4月、<http://www.rfc-editor.org/info/rfc4466>。

[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 2006, <http://www.rfc-editor.org/info/rfc4469>.

[RFC4469] Resnick、P。、「インターネットメッセージアクセスプロトコル（IMAP）CATENATE拡張機能」、RFC 4469、DOI 10.17487 / RFC4469、2006年4月、<http://www.rfc-editor.org/info/rfc4469>。

11.2. Informative References
11.2. 参考引用

[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, March 2003, <http://www.rfc-editor.org/info/rfc3502>.

[RFC3502] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP）-MULTIAPPEND拡張機能」、RFC 3502、DOI 10.17487 / RFC3502、2003年3月、<http://www.rfc-editor.org/info/rfc3502>。

[RFC7889] SrimushnamBoovaraghamoorthy, J. and N. Bisht, "The IMAP APPENDLIMIT Extension", RFC 7889, DOI 10.17487/RFC7889, May 2016, <http://www.rfc-editor.org/info/rfc7889>.

[RFC7889] SrimushnamBoovaraghamoorthy、J。およびN. Bisht、「The IMAP APPENDLIMIT Extension」、RFC 7889、DOI 10.17487 / RFC7889、May 2016、<http://www.rfc-editor.org/info/rfc7889>。

Appendix A. Changes since RFC 2088
付録A. RFC 2088以降の変更

Added IANA registration.

IANA登録を追加しました。

Updated references. Also updated considerations about interactions of IMAP extensions.

更新された参照。 IMAP拡張機能の相互作用に関する考慮事項も更新されました。

Added implementation considerations based on the IMAP mailing list discussions.

IMAPメーリングリストのディスカッションに基づく実装に関する考慮事項を追加しました。

Added description of a new capability: LITERAL-.

新しい機能の説明が追加されました：LITERAL-。

Acknowledgments

謝辞

John G. Myers edited the original LITERAL+ extension.

John G. Myersが元のLITERAL +拡張を編集しました。

Valuable comments, both in agreement and in dissent, were received from Dave Cridland, Michael M. Slusarz, Arnt Gulbrandsen, Jayantheesh SrimushnamBoovaraghamoorthy, Jamie Nicolson, Barry Leiba, and SM.

価値あるコメントは、合意と反対の両方で、Dave Cridland、Michael M. Slusarz、Arnt Gulbrandsen、Jayantheesh SrimushnamBoovaraghamoorthy、Jamie Nicolson、Barry Leiba、およびSMから受け取りました。

Author's Address

著者のアドレス

Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom

Alexey Melnikov（編集者）Isode Ltd 14 Castle Mewsハンプトン、ミドルセックスTW12 2NPイギリス 

   Email: Alexey.Melnikov@isode.com