RFC 7889 - The IMAP APPENDLIMIT Extension 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7889
タイトル : RFC 7889 - IMAP APPENDLIMIT拡張
翻訳編集 : 自動生成

[要約] RFC 7889は、IMAP APPENDLIMIT拡張機能に関する仕様であり、IMAPサーバーがメールボックスに追加できるメッセージの制限を設定するための方法を提供します。目的は、サーバーのリソースを効果的に管理し、パフォーマンスを向上させることです。

Internet Engineering Task Force (IETF)    J. SrimushnamBoovaraghamoorthy
Request for Comments: 7889                                      N. Bisht
Category: Standards Track                    Samsung Electronics America
ISSN: 2070-1721                                                 May 2016

The IMAP APPENDLIMIT Extension

IMAP APPENDLIMIT拡張

Abstract

概要

This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large.

このドキュメントでは、IMAPサービスの拡張を定義します。これにより、サーバーは最大メッセージアップロードサイズをクライアントに通知でき、メッセージが大きすぎるために失敗するAPPENDコマンドの送信をクライアントが回避できます。

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/rfc7889.

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

著作権表示

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に記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . .   3
   3.  Mailbox-Specific APPENDLIMIT  . . . . . . . . . . . . . . . .   3
     3.1.  STATUS Response to the STATUS Command . . . . . . . . . .   4
     3.2.  STATUS Response to the LIST Command . . . . . . . . . . .   4
     3.3.  APPENDLIMIT Behavior  . . . . . . . . . . . . . . . . . .   4
   4.  APPEND Response . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction

1. はじめに

Some IMAP servers have limits for message upload size, and those limits are not published to the email client. When the email client APPENDs a message with huge attachments, using non-synchronizing literals, the APPEND fails because of the upload limit, but the client has already sent the message data anyway. This results in unnecessary resource usage. Especially in the mobile device environment, appending a message with huge attachments consumes device resources like device battery power and mobile data.

一部のIMAPサーバーにはメッセージのアップロードサイズに制限があり、それらの制限は電子メールクライアントに公開されません。電子メールクライアントが非同期のリテラルを使用して巨大な添付ファイルを含むメッセージをAPPENDすると、アップロード制限のためAPPENDは失敗しますが、クライアントはすでにメッセージデータを送信しています。これにより、不要なリソースが使用されます。特にモバイルデバイス環境では、巨大な添付ファイルを含むメッセージを追加すると、デバイスのバッテリー電力やモバイルデータなどのデバイスリソースが消費されます。

The IMAP APPENDLIMIT extension provides the ability to advertise a maximum upload size allowed by the IMAP server, so that the email client knows the size limitation beforehand. By implementing this extension, IMAP server-side processing of huge attachments above the maximum upload size can be avoided.

IMAP APPENDLIMIT拡張機能は、IMAPサーバーで許可される最大アップロードサイズをアドバタイズする機能を提供します。これにより、電子メールクライアントはサイズの制限を事前に認識できます。この拡張機能を実装することにより、最大アップロードサイズを超える巨大な添付ファイルのIMAPサーバー側処理を回避できます。

1.1. Conventions

1.1. 規約

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

2. APPENDLIMIT Extension

2. APPENDLIMIT拡張

An IMAP server that supports the APPENDLIMIT extension advertises this by including the name APPENDLIMIT in its capability list in the authenticated state. The server may also advertise this extension before the user has logged in. If this capability is omitted, no information is conveyed about the server's fixed maximum size for mail uploads. An IMAP server can publish the APPENDLIMIT capability in two formats.

APPENDLIMIT拡張をサポートするIMAPサーバーは、認証済み状態の機能リストにAPPENDLIMITという名前を含めることでこれをアドバタイズします。サーバーは、ユーザーがログインする前にこの拡張機能をアドバタイズする場合もあります。この機能が省略されている場合、メールアップロード用のサーバーの固定最大サイズに関する情報は伝達されません。 IMAPサーバーは、APPENDLIMIT機能を2つの形式で公開できます。

   (a) APPENDLIMIT=<number>

This indicates that the IMAP server has the same upload limit for all mailboxes. The following example demonstrates the APPENDLIMIT capability with the same upload limit for all mailboxes.

これは、IMAPサーバーがすべてのメールボックスに対して同じアップロード制限を持っていることを示しています。次の例は、すべてのメールボックスに同じアップロード制限があるAPPENDLIMIT機能を示しています。

   C: t1 CAPABILITY
   S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
   S: t1 OK foo

(b) APPENDLIMIT

（b）追加制限

The APPENDLIMIT capability without any value indicates that the IMAP server supports this extension, and that the client will need to discover upload limits for each mailbox, as they might differ from mailbox to mailbox. The following example demonstrates the APPENDLIMIT capability without any value.

値のないAPPENDLIMIT機能は、IMAPサーバーがこの拡張機能をサポートしていること、およびメールボックスごとに異なる可能性があるため、クライアントが各メールボックスのアップロード制限を検出する必要があることを示します。次の例は、値のないAPPENDLIMIT機能を示しています。

   C: t1 CAPABILITY
   S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
   S: t1 OK foo

In this case, the client can get an APPENDLIMIT value by either issuing a STATUS or a LIST command.

この場合、クライアントはSTATUSコマンドまたはLISTコマンドを発行することにより、APPENDLIMIT値を取得できます。

An IMAP client implementing this extension should be able to parse both mailbox-specific and global APPENDLIMIT responses. By looking at the upload size advertised by the IMAP server, a client can avoid trying to APPEND mail more than the advertised limit.

この拡張機能を実装するIMAPクライアントは、メールボックス固有の応答とグローバルなAPPENDLIMIT応答の両方を解析できる必要があります。 IMAPサーバーによってアドバタイズされるアップロードサイズを確認することで、クライアントはアドバタイズされた制限を超えてメールを追加しようとすることを回避できます。

3. Mailbox-Specific APPENDLIMIT

3. メールボックス固有のAPPENDLIMIT

An IMAP server can have mailbox-specific APPENDLIMIT values that will not be advertised as part of the CAPABILITY response. The IMAP server can publish specific values for each mailbox, and it can publish "NIL" for a mailbox to convey that there is no APPENDLIMIT for that mailbox. The following subsections describe the changes to the STATUS and LIST commands in support of this situation.

IMAPサーバーは、CAPABILITY応答の一部として通知されないメールボックス固有のAPPENDLIMIT値を持つことができます。 IMAPサーバーはメールボックスごとに特定の値を公開できます。また、メールボックスに「NIL」を公開して、そのメールボックスにAPPENDLIMITがないことを伝えることができます。以下のサブセクションでは、この状況をサポートするためのSTATUSコマンドとLISTコマンドの変更について説明します。

3.1. STATUS Response to the STATUS Command

3.1. STATUSコマンドに対するSTATUS応答

A new attribute APPENDLIMIT is added to get the limit set by the server for a mailbox as part of a STATUS command. An IMAP client should issue a STATUS command with an APPENDLIMIT item to get the mailbox-specific upload value. The following example demonstrates its usage.

新しい属性APPENDLIMITが追加され、STATUSコマンドの一部としてサーバーがメールボックスに設定した制限を取得します。 IMAPクライアントは、メールボックス固有のアップロード値を取得するために、APPENDLIMITアイテムを指定したSTATUSコマンドを発行する必要があります。次の例は、その使用法を示しています。

   C: t1 STATUS INBOX (APPENDLIMIT)
   S: * STATUS INBOX (APPENDLIMIT 257890)
   S: t1 OK STATUS completed

In the above example, APPENDLIMIT represents the maximum upload size for INBOX.

上記の例では、APPENDLIMITはINBOXの最大アップロードサイズを表します。

3.2. STATUS Response to the LIST Command

3.2. LISTコマンドに対するSTATUS応答

If the server advertises the LIST-STATUS capability [RFC5819], the client can issue a LIST command in combination with the STATUS return option to get the mailbox-specific upload value. The following example demonstrates its usage.

サーバーがLIST-STATUS機能[RFC5819]を通知する場合、クライアントはLISTコマンドをSTATUSリターンオプションと組み合わせて発行して、メールボックス固有のアップロード値を取得できます。次の例は、その使用法を示しています。

   C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT))
   S: * LIST () "."  "INBOX"
   S: * STATUS "INBOX" (APPENDLIMIT 257890)
   S: t1 OK List completed.

The IMAP server MUST recognize the APPENDLIMIT attribute and include an appropriate STATUS response for each matching mailbox. Refer to Section 5 for the syntax.

IMAPサーバーはAPPENDLIMIT属性を認識し、一致するメールボックスごとに適切なSTATUS応答を含める必要があります。構文については、セクション5を参照してください。

If the server does not support the STATUS return option on the LIST command, then the client should use the STATUS command instead.

サーバーがLISTコマンドのSTATUS戻りオプションをサポートしていない場合、クライアントは代わりにSTATUSコマンドを使用する必要があります。

3.3. APPENDLIMIT Behavior

3.3. APPENDLIMITの動作

Computing the APPENDLIMIT should be fast and should not take Access Control Lists (ACLs), quotas, or other such information into account. The APPENDLIMIT specifies one part of the policy, but an APPEND command can still fail due to issues related to ACLs and quotas, even if the message being appended is smaller than the APPENDLIMIT.

APPENDLIMITの計算は高速である必要があり、アクセス制御リスト（ACL）、クォータ、またはその他のそのような情報を考慮に入れないでください。 APPENDLIMITはポリシーの一部を指定しますが、追加されるメッセージがAPPENDLIMITより小さい場合でも、ACLと割り当てに関連する問題が原因でAPPENDコマンドが失敗する可能性があります。

4. APPEND Response

4. APPEND応答

If a client uploads a message that exceeds the maximum upload size set for that mailbox, then the server SHALL reject the APPEND command with a tagged TOOBIG response code. Refer to Section 4 of [RFC4469] for various APPEND response codes and their handling.

クライアントがそのメールボックスに設定された最大アップロードサイズを超えるメッセージをアップロードした場合、サーバーはタグ付けされたTOOBIG応答コードを持つAPPENDコマンドを拒否するものとします（SHALL）。さまざまなAPPEND応答コードとその処理については、[RFC4469]のセクション4を参照してください。

A client SHOULD avoid use of non-synchronizing literals [RFC7888] when the maximum upload size supported by the IMAP server is unknown. Refer to Section 4.2.2.3 of [RFC4549] for usage of non-synchronizing literals and its risk for disconnected IMAP clients.

IMAPサーバーがサポートする最大アップロードサイズが不明な場合、クライアントは非同期リテラル[RFC7888]の使用を避けるべきです。非同期リテラルの使用と切断されたIMAPクライアントのリスクについては、[RFC4549]のセクション4.2.2.3を参照してください。

5. Formal Syntax

5. 正式な構文

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234] including the core rules in Appendix B.1 of that document. [RFC3501] defines the non-terminals "capability" and "status-att", and [RFC4466] defines "status-att-val".

次の構文仕様では、[RFC5234]で指定されている拡張バッカスナウア記法（ABNF）表記を使用し、そのドキュメントの付録B.1にあるコアルールを含めています。 [RFC3501]は非端末の「機能」と「status-att」を定義し、[RFC4466]は「status-att-val」を定義します。

All alphabetic characters are case insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.

すべてのアルファベット文字は大文字と小文字を区別しません。トークン文字列を定義するための大文字または小文字の使用は、編集上の明確さのためだけです。実装は、大文字と小文字を区別しない方法でこれらの文字列を受け入れる必要があります。

   capability =/ "APPENDLIMIT" ["=" number]
               ;; capability is defined in RFC 3501

   status-att =/ "APPENDLIMIT"
               ;; status-att is defined in RFC 3501

   status-att-val =/ "APPENDLIMIT" SP (number / nil)
                   ;; status-att-val is defined in RFC 4466

The number indicates the fixed maximum message size in octets that the server will accept. An APPENDLIMIT number of 0 indicates the server will not accept any APPEND commands at all for the affected mailboxes.

数値は、サーバーが受け入れる固定オクテットの最大メッセージサイズを示します。 APPENDLIMITの数値が0の場合、影響を受けるメールボックスに対してサーバーがAPPENDコマンドをまったく受け付けないことを示します。

6. Security Considerations

6. セキュリティに関する考慮事項

This extension provides additional information that cooperative clients can use as an optimization and does not introduce new security concerns. This extension does not address abusive clients that intend to consume server resources, and servers will still have to take action to disconnect and/or restrict access to clients that exhibit abusive behavior.

この拡張機能は、協調型クライアントが最適化として使用できる追加情報を提供し、新しいセキュリティ上の懸念をもたらしません。この拡張機能は、サーバーリソースを消費する悪意のあるクライアントには対応していません。サーバーは、悪意のある動作を示すクライアントへのアクセスを切断したり、アクセスを制限したりする必要があります。

7. IANA Considerations

7. IANAに関する考慮事項

IANA has added "APPENDLIMIT" to the "IMAP Capabilities" registry, using this document as its reference.

IANAは、このドキュメントを参照として使用して、「APPENDLIMIT」を「IMAP Capabilities」レジストリに追加しました。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[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>。

[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>。

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

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

[RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for Returning STATUS Information in Extended LIST", RFC 5819, DOI 10.17487/RFC5819, March 2010, <http://www.rfc-editor.org/info/rfc5819>.

[RFC5819] Melnikov、A。およびT. Sirainen、「拡張リストでステータス情報を返すためのIMAP4拡張機能」、RFC 5819、DOI 10.17487 / RFC5819、2010年3月、<http://www.rfc-editor.org/info/ rfc5819>。

[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals", RFC 7888, DOI 10.17487/RFC7888, May 2016, <http://www.rfc-editor.org/info/rfc7888>.

[RFC7888] Melnikov、A。、編、「IMAP4非同期リテラル」、RFC 7888、DOI 10.17487 / RFC7888、2016年5月、<http://www.rfc-editor.org/info/rfc7888>。

8.2. Informative References

8.2. 参考引用

[RFC4549] Melnikov, A., Ed., "Synchronization Operations for Disconnected IMAP4 Clients", RFC 4549, DOI 10.17487/RFC4549, June 2006, <http://www.rfc-editor.org/info/rfc4549>.

[RFC4549] Melnikov、A。、編、「切断されたIMAP4クライアントの同期操作」、RFC 4549、DOI 10.17487 / RFC4549、2006年6月、<http://www.rfc-editor.org/info/rfc4549>。

Acknowledgements

謝辞

Thanks to Alexey Melnikov, Dave Cridland, Adrien de Croy, Michael M. Slusarz, Timo Sirainen, Chris Newman, Pete Maclean, Jamie Nicolson, Stu Brandt, Bron Gondwana, Arnt Gulbrandsen, Cyrus Daboo, Jan Kundrat, Brandon Long, and Barry Leiba for providing valuable comments.

Alexey Melnikov、Dave Cridland、Adrien de Croy、Michael M. Slusarz、Timo Sirainen、Chris Newman、Pete Maclean、Jamie Nicolson、Stu Brandt、Bron Gondwana、Arnt Gulbrandsen、Cyrus Daboo、Jan Kundrat、Brandon Long、Barry Leibaに感謝貴重なコメントを提供してくれた。

Authors' Addresses

著者のアドレス

Jayantheesh SrimushnamBoovaraghamoorthy Samsung Electronics America 685 US Highway 202/206 Bridgewater, NJ 08807 United States

Jayantheesh SrimushnamBoovaraghamoorthy Samsung Electronics America 685 US Highway 202/206 Bridgewater、NJ 08807 United States

   Email: jayantheesh.sb@gmail.com

Narendra Singh Bisht Samsung Electronics America 685 US Highway 202/206 Bridgewater, NJ 08807 United States

Narendra Singh Bisht Samsung Electronics America 685 US Highway 202/206 Bridgewater、NJ 08807 United States

   Email: narendrasingh.bisht@gmail.com