[要約] RFC 9208 は IMAP QUOTA 拡張機能を定義し、IMAP プロトコルを介してリソース使用量の管理制限（クォータ）を操作することを可能にします。RFC 2087 を廃止し、後方互換性を保ちつつ、IMAP の管理制限を操作するための標準を提供します。
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 9208 Isode
Obsoletes: 2087 March 2022
Category: Standards Track
ISSN: 2070-1721
IMAP QUOTA Extension
IMAPクォータ拡張
Abstract
概要
This document defines a QUOTA extension of the Internet Message Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.
このドキュメントは、IMAPプロトコルを介して操作されるリソース使用量（クォータ）の管理制限を許可する、インターネットメッセージアクセスプロトコル（IMAP）のクォータ拡張（RFCS 3501および9051を参照）を定義します。
This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible.
この文書はRFC 2087を廃止しますが、可能な限り互換性のある互換性が試みられます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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 https://www.rfc-editor.org/info/rfc9208.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc9208で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
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標準プロセスの外部にはデリバティブワークが作成できません。RFCとしての出版物、または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction and Overview
2. Document Conventions
3. Terms
3.1. Resource
3.1.1. Name
3.1.2. Definition
3.2. Quota Root
4. Definitions
4.1. Commands
4.1.1. GETQUOTA
4.1.2. GETQUOTAROOT
4.1.3. SETQUOTA
4.1.4. New STATUS attributes
4.2. Responses
4.2.1. QUOTA
4.2.2. QUOTAROOT
4.3. Response Codes
4.3.1. OVERQUOTA
5. Resource Type Definitions
5.1. STORAGE
5.2. MESSAGE
5.3. MAILBOX
5.4. ANNOTATION-STORAGE
6. Interaction with IMAP ACL Extension (RFC 4314)
7. Formal Syntax
8. Security Considerations
9. IANA Considerations
9.1. Changes/Additions to the IMAP Capabilities Registry
9.2. IMAP Quota Resource Type Registry
10. Changes Since RFC 2087
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Contributors
Author's Address
This document defines a couple of extensions to the Internet Message Access Protocol [RFC3501] [RFC9051] for querying and manipulating administrative limits on resource usage (quotas). This extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
このドキュメントは、リソース使用量（クォータ）の管理限界を問い合わせると操作するための、インターネットメッセージアクセスプロトコル[RFC3501] [RFC9051]への拡張数を定義します。この拡張子は、IMAP4REV1 [RFC3501]とIMAP4REV2 [RFC9051]の両方に互換性があります。
The "QUOTA" capability denotes a server compliant with [RFC2087]. Some responses and response codes defined in this document are not present in such servers (see Section 10 for more details), and clients MUST NOT rely on their presence in the absence of any capability beginning with "QUOTA=".
"クォータ"機能は、[RFC2087]に準拠したサーバーを表します。このドキュメントで定義されている応答コードと応答コードは、そのようなサーバーには存在しません（詳細についてはセクション10を参照）、クライアントは "quota ="で始まる機能がない場合は存在しません。
Any server compliant with this document MUST also return at least one capability starting with the "QUOTA=RES-" prefix, as described in Section 3.1.
この文書に準拠したサーバーは、セクション3.1で説明されているように、 "quota = res-"プレフィックスから始まる少なくとも1つの機能を返す必要があります。
Any server compliant with this document that implements the SETQUOTA command (see Section 4.1.3) MUST also return the "QUOTASET" capability.
setquotaコマンドを実装するこのドキュメントに準拠したサーバー（セクション4.1.3を参照）も "クォーセット"機能を返す必要があります。
This document also reserves all other capabilities starting with the "QUOTA=" prefix for future IETF Stream Standard Track, Informational, or Experimental extensions to this document.
このドキュメントでは、将来のIETF Stream Standard Track、Informational、Informatal拡張、または実験的な拡張について、 "quota ="プレフィックスで始まる他のすべての機能も予約します。
Quotas can be used to restrict clients for administrative reasons, but the QUOTA extension can also be used to indicate system limits and current usage levels to clients.
クォータは、管理上の理由からクライアントを制限するために使用できますが、クォータの拡張子を使用して、システム制限と現在の使用レベルをクライアントに示すこともできます。
Although the IMAP4 QUOTA extension specified in [RFC2087] has seen deployment in servers, it has seen little deployment in clients. Since the meaning of the resources was implementation dependent, it was impossible for a client implementation to determine which resources were supported, and it was impossible to determine which mailboxes were in a given quota root (see Section 3.2) without a priori knowledge of the implementation.
[RFC2087]で指定されたIMAP4クォータ拡張機能は、サーバー内の展開を見ましたが、クライアントにはほとんど展開を見ました。リソースの意味は実装に依存しているため、クライアントの実装がどのリソースがサポートされていたかを判断することは不可能であり、実装に関する先験的な知識がなくても、特定のメールボックス（セクション3.2を参照）を決定することは不可能でした。。
In protocol examples, this document uses a prefix of "C: " to denote lines sent by the client to the server and "S: " for lines sent by the server to the client. Lines prefixed with "//" are comments explaining the previous protocol line. These prefixes and comments are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line break is present in the protocol before such lines unless specifically mentioned.
プロトコル例では、このドキュメントでは「C：」の接頭辞を使用して、クライアントによってサーバーから送信された行を、サーバーからクライアントに送信された行に対して "S："を表します。"//"の前に配線されている行は、以前のプロトコル行を説明するコメントです。これらの接頭辞とコメントはプロトコルの一部ではありません。これらの接頭辞のいずれも前の行の継続であり、特に言及されていない限り、このような行の前にプロトコル内にラインブレークは存在しません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Other capitalized words are IMAP keywords [RFC3501] [RFC9051] or keywords from this document.
その他の大文字の単語は、IMAPキーワード[RFC3501] [RFC9051]またはこの文書のキーワードです。
A resource has a name, a formal definition.
リソースには名前、正式な定義があります。
The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. These MUST be registered with IANA.
リソース名は、IMAP4REV1 [RFC3501]で定義されているように、原子です。これらはIANAに登録されなければなりません。
Supported resource names MUST be advertised as a capability by prepending the resource name with "QUOTA=RES-". A server compliant with this specification is not required to support all reported resource types on all quota roots.
サポートされているリソース名は、リソース名を "quota = res-"で追加することによって機能としてアドバタイズする必要があります。この仕様に準拠したサーバーは、すべてのクォータルートで報告されたすべてのリソースタイプをサポートする必要はありません。
The resource definition or document containing it, while not visible through the protocol, SHOULD be registered with IANA.
プロトコルを介して見えない一方で、それを含むリソース定義または文書はIANAに登録されるべきです。
The usage of a resource MUST be represented as a 63-bit unsigned integer. 0 indicates that the resource is exhausted. Usage integers don't necessarily represent proportional use, so clients MUST NOT compare an available resource between two separate quota roots on the same or different servers.
リソースの使用法は63ビットの符号なし整数として表されている必要があります。0はリソースが使い果たされていることを示します。使用整数は必ずしも比例使用を表すわけではないため、クライアントは同じまたは異なるサーバー上の2つの別々のクォータルート間の利用可能なリソースを比較してはなりません。
Limits will be specified as, and MUST be represented as, an integer. 0 indicates that any usage is prohibited.
制限はそのままに指定され、整数として表現する必要があります。0使用方法が禁止されていることを示します。
Limits may be hard or soft; that is, an implementation MAY choose, or be configured, to disallow any command if the limit on a resource is or would be exceeded.
制限は硬いか柔らかいかもしれません。つまり、実装は、リソース上の制限が超過または超過する場合は、どのコマンドを許可するかを選択または設定することができます。
All resources that the server handles MUST be advertised in a CAPABILITY response/response code consisting of the resource name prefixed by "QUOTA=RES-".
サーバーのハンドルを処理するすべてのリソースは、 "quota = res-"でプレフィックスされたリソース名からなる機能応答/応答コードでアドバタイズする必要があります。
The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX (Section 5.3), and ANNOTATION-STORAGE (Section 5.4) are defined in this document.
このドキュメントでは、リソースストレージ（セクション5.1）、メッセージ（5.2）、メールボックス（セクション5.3）、および注釈ストレージ（セクション5.4）が定義されています。
This document introduces the concept of a "quota root", as resource limits can apply across multiple IMAP mailboxes.
この文書では、リソースの制限が複数のIMAPメールボックスに適用できるため、「クォータルート」の概念を紹介します。
Each mailbox has zero or more implementation-defined named "quota roots". Each quota root has zero or more resource limits (quotas). All mailboxes that share the same named quota root share the resource limits of the quota root.
各メールボックスには、0個以上の実装定義が定義された "クォータルート"です。各クォータルートには、ゼロ以上のリソース制限（クォータ）があります。同じ名前のクォータルートを共有するすべてのメールボックスは、クォータルートのリソース制限を共有します。
Quota root names need not be mailbox names, nor is there any relationship defined by this document between a quota root name and a mailbox name. A quota root name is an astring, as defined in IMAP4 [RFC3501] [RFC9051]. It SHOULD be treated as an opaque string by any clients.
クォータルート名はメールボックス名である必要もなく、クォータルート名とメールボックス名の間にこの文書によって定義されていません。IMAP4 [RFC3501] [RFC9051]で定義されているように、クォータのルート名は揃っています。それは任意のクライアントによって不透明な文字列として扱われるべきです。
Quota roots are used since not all implementations may be able to calculate usage, or apply quotas, on arbitrary mailboxes or mailbox hierarchies.
すべての実装がすべての実装を計算したり、任意のメールボックスやメールボックスの階層にクォータを適用できるとは限らないため、クォータルートが使用されます。
Not all resources may be limitable or calculable for all quota roots. Furthermore, not all resources may support all limits; some limits may be present in the underlying system. A server implementation of this memo SHOULD advise the client of such inherent limits, by generating QUOTA (Section 4.2.1) responses, and SHOULD advise the client of which resources are limitable for a particular quota root. A SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an implementation-dependent way, if the granularity of the underlying system demands it. A client MUST be prepared for a SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set.
すべてのリソースがすべてのクォータルートに対して制限的または計算可能ではないわけではありません。さらに、すべてのリソースがすべての制限をサポートできるわけではありません。基礎となるシステムにはいくつかの制限があるかもしれません。このメモのサーバー実装は、クォータを生成することによって、そのような固有の制限のクライアントにアドバイスする必要があります（セクション4.2.1）応答を生成する必要があり、そのクライアントが特定のクォータルートに対して制限されるクライアントにアドバイスする必要があります。基礎となるシステムの細分性がそれを要求する場合、SetQuota（セクション4.1.3）コマンドは実装に依存する方法でクォータ制限を丸めることもできます。制限を設定できない場合、SetQuota（セクション4.1.3）コマンドのクライアントを作成する必要があります。
Implementation Notes: This means that, for example, under UNIX, a quota root may have a MESSAGE (Section 5.2) quota always set due to the number of inodes available on the filesystem; similarly, STORAGE (Section 5.1) may be rounded to the nearest block and limited by free filesystem space.
実装上の注意：これは、たとえば、UNIXの下で、クォータルートがメッセージシステム（セクション5.2）を持つことができることを意味します。同様に、ストレージ（セクション5.1）は最も近いブロックに丸められ、無料のファイルシステムスペースによって制限されることがあります。
The following commands exist for manipulation and querying quotas.
以下のコマンドは、クォータの操作とクエリのクエリのために存在します。
Arguments: quota root
引数：クォータルート
Responses: REQUIRED untagged responses: QUOTA
応答：必要なアンタグな応答：クォータ
Result: OK - getquota completed
結果：OK - GetQuotaが完成しました
NO - getquota error: no such quota root, permission denied
いいえ - GetQuotaエラー：そのようなクォータルート、許可が拒否されました
BAD - command unknown or arguments invalid
bad - 不明または引数が無効です
The GETQUOTA command takes the name of a quota root and returns the quota root's resource usage and limits in an untagged QUOTA response. (Names of quota roots applicable to a particular mailbox can be discovered by issuing the GETQUOTAROOT command; see Section 4.1.2.) Note that the server is not required to support any specific resource type (as advertised in the CAPABILITY response, i.e., all capability items with the "QUOTA=RES-" prefix) for any particular quota root.
getquotaコマンドはクォータルートの名前を取り、クォータルートのリソース使用量とタグなしクォータの応答の制限を返します。（特定のメールボックスに適用されるクォータルートの名前はgetquotarootコマンドを発行することによって発見することができます。4.1.2節を参照してください。）サーバーは、特定のリソースタイプをサポートする必要はありません（能力の対応で宣伝されているように、つまりすべて、すべて特定のクォータルートに対して「クォータ= res-プレフィックス」を持つ機能項目。
Example:
例：
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...]
[...]
[...]
C: G0001 GETQUOTA "!partition/sda4"
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
S: G0001 OK Getquota complete
S：G0001 OK GetQuota Complete
Arguments: mailbox name
引数：メールボックスの名前
Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA
応答：必要なアンタグな応答：Quotaroot、クォータ
Result: OK - getquotaroot completed
結果：OK - GetQuotaroot完了
NO - getquotaroot error: permission denied
いいえ - GetQuotarootエラー：権限が拒否されました
BAD - command unknown or arguments invalid
bad - 不明または引数が無効です
The GETQUOTAROOT command takes a mailbox name and returns the list of quota roots for the mailbox in an untagged QUOTAROOT response. For each listed quota root, it also returns the quota root's resource usage and limits in an untagged QUOTA response.
GetQuotArootコマンドはメールボックス名を取り、タグなしのクォータクォート応答でメールボックスのクォータルートのリストを返します。リストされている各クォータルートについて、クォータルートのリソース使用量とタグなしクォータの応答の制限も返します。
Note that the mailbox name parameter doesn't have to reference an existing mailbox. This can be handy in order to determine which quota root would apply to a mailbox when it gets created.
メールボックス名パラメータは既存のメールボックスを参照する必要はありません。これは、どのクォータルートが作成されたときにどのクォータルートがメールボックスに適用されるかを判断するために便利です。
Example:
例：
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
[...]
[...]
[...]
C: G0002 GETQUOTAROOT INBOX
C：G0002 GetQuotaroot受信箱
S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4"
S: * QUOTA "#user/alice" (MESSAGE 42 1000)
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
S: G0002 OK Getquotaroot complete
S：G0002 OK GetQuotaroot Complete
Arguments: quota root list of resource limits
引数：リソース制限のクォータルートリスト
Responses: untagged responses: QUOTA
応答：タグなし応答：クォータ
Result: OK - setquota completed
結果：OK - SetQuotaが完成しました
NO - setquota error: can't set that data
いいえ - SetQuotaエラー：そのデータを設定できません
BAD - command unknown or arguments invalid
bad - 不明または引数が無効です
Note that unlike other command/responses/response codes defined in this document, support for the SETQUOTA command requires the server to advertise the "QUOTASET" capability.
このドキュメントで定義されている他のコマンド/応答/応答コードとは異なり、setquotaコマンドのサポートはサーバーが "クォーセット"機能をアドバタイズする必要があります。
The SETQUOTA command takes the name of a mailbox quota root and a list of resource limits. The resource limits for the named quota root are changed to the specified limits. Any previous resource limits for the named quota root are discarded, even resource limits not explicitly listed in the SETQUOTA command. (For example, if the quota root had both STORAGE and MESSAGE limits assigned to the quota root before the SETQUOTA is called and the SETQUOTA only includes the STORAGE limit, then the MESSAGE limit is removed from the quota root.)
setquotaコマンドは、メールボックスクォータルートの名前とリソース制限のリストを取ります。指定されたクォータルートのリソース制限は、指定された制限に変更されます。名前付きクォータルートの以前のリソース制限は破棄されます。（たとえば、SetQuotaが呼び出される前にクォータルートに割り当てられているストレージとメッセージ制限の両方がクォータルートに割り当てられ、SetQuotaのみが含まれている場合は、メッセージ制限はクォータルートから削除されます。）
If the named quota root did not previously exist, an implementation may optionally create it and change the quota roots for any number of existing mailboxes in an implementation-defined manner.
名前付きクォータルートが以前に存在しなかった場合、実装はオプションでそれを作成し、実装定義の方法で任意の数の既存のメールボックスのクォータルートを変更することができます。
If the implementation chooses to change the quota roots for some existing mailboxes, such changes SHOULD be announced with untagged QUOTA responses.
実装が既存のメールボックスのクォータルートを変更することを選択した場合、そのような変更はタグなしクォータの応答で発表されるべきです。
Example:
例：
S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES-
MESSAGE [...]
[...]
[...]
C: S0000 GETQUOTA "#user/alice"
S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000)
S: S0000 OK Getquota completed
S：S0000 OK GetQuota完成品
C: S0001 SETQUOTA "#user/alice" (STORAGE 510)
S: * QUOTA "#user/alice" (STORAGE 58 512)
// The server has rounded the STORAGE quota limit requested to the nearest 512 blocks of 1024 octets; otherwise, another client has performed a near-simultaneous SETQUOTA using a limit of 512.
//サーバーは1024オクテットの最も近い512ブロックに要求されたストレージクォータ制限を四捨五入しました。それ以外の場合、別のクライアントは、512の制限を使用して同時に近似したSetQuotaを実行しました。
S: S0001 OK Rounded quota
S：S0001 OK丸みを帯びたクォータ
C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999)
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
// The server has not changed the quota, since this is a filesystem limit, and it cannot be changed. The QUOTA response here is entirely optional.
//サーバーはファイルシステムの制限なので、サーバーはクォータを変更しておらず、変更できません。ここでクォータの応答は完全にオプションです。
S: S0002 NO Cannot change system limit
S：S0002いいえシステムの制限を変更できません
The DELETED and DELETED-STORAGE status data items allow for estimation of the amount of resources that could be freed by an EXPUNGE on a mailbox.
削除された削除されたストレージのステータスデータ項目は、メールボックス上のエクスンゲーによって解放される可能性のあるリソースの量の推定を可能にします。
The DELETED status data item requests the server to return the number of messages with the \Deleted flag set. The DELETED status data item is only required to be implemented when the server advertises the "QUOTA=RES-MESSAGE" capability.
削除されたステータスデータ項目は、サーバーに\ Deleted Flag Setを持つメッセージ数を返すように要求します。削除されたステータスデータ項目は、サーバーが "Quota = Res-Message"機能を提供するときにのみ実装される必要があります。
The DELETED-STORAGE status data item requests the server to return the amount of storage space that can be reclaimed by performing EXPUNGE on the mailbox. The server SHOULD return the exact value; however, it is recognized that the server may have to do a non-trivial amount of work to calculate it. If the calculation of the exact value would take a long time, the server MAY instead return the sum of the RFC822.SIZE of the messages with the \Deleted flag set. The DELETED-STORAGE status data item is only required to be implemented when the server advertises the "QUOTA=RES-STORAGE" capability.
削除されたストレージステータスデータ項目は、メールボックス上でExpunggeを実行することによって再生できるストレージスペースの量を返すようにサーバーに要求します。サーバーは正確な値を返すべきです。ただし、サーバーがそれを計算するために些細な作業をする必要があるかもしれないことが認識されています。正確な値の計算に時間がかかる場合、サーバーは代わりにメッセージのRFC822.SIZEの合計を\ Deleted Flag Setに返します。削除されたストレージステータスデータ項目は、サーバーが "Quota = Res-Storage"機能を提供するときにのみ実装される必要があります。
Example:
例：
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-
MESSAGE [...]
[...]
[...]
C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
C：S0003ステータス受信トレイ（メッセージが削除されたメッセージを削除しました）
S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
■*ステータス受信トレイ（メッセージ12削除された4削除済みストレージ8）
// 12 messages, 4 of which would be deleted when an EXPUNGE happens.
// 12のメッセージは、4のうち4のうち4つが削除されます。
S: S0003 OK Status complete.
S：S0003 OKステータスが完了しました。
The following responses may be sent by the server.
次の応答はサーバーによって送信される可能性があります。
Data: quota root name
データ：クォータルート名
list of resource names, usages, and limits
リソース名、使用方法、および制限のリスト
This response occurs as a result of a GETQUOTA, GETQUOTAROOT, or SETQUOTA command. The first string is the name of the quota root for which this quota applies.
この応答は、GetQuota、GetQuotaroot、またはsetquotaコマンドの結果として発生します。最初の文字列は、このクォータが適用されるクォータルートの名前です。
The name is followed by an S-expression format list of the resource usage and limits of the quota root. The list contains zero or more triplets. Each triplet contains a resource name, the current usage of the resource, and the resource limit.
名前はその後にS-Expression Format of Resource Rootのrootのリミットリストが続きます。リストには0以上のトリプレットが含まれています。各トリプレットには、リソース名、リソースの現在の使用法、およびリソース制限が含まれています。
Resources not named in the list are not limited in the quota root. Thus, an empty list means there are no administrative resource limits in the quota root.
リストで名前が付けられていないリソースは、クォータルートでは制限されません。したがって、空のリストは、クォータルートに管理者リソース制限がないことを意味します。
Example:
例：
S: * QUOTA "" (STORAGE 10 512)
S：*クォータ ""（ストレージ10 512）
Data: mailbox name
データ：メールボックスの名前
zero or more quota root names
ゼロまたはそれ以上のクォータのルート名
This response occurs as a result of a GETQUOTAROOT command. The first string is the mailbox and the remaining strings are the names of the quota roots for the mailbox.
この応答はgetquotarootコマンドの結果として発生します。最初の文字列はメールボックスで、残りの文字列はメールボックスのクォータルートの名前です。
Examples:
例：
S: * QUOTAROOT INBOX ""
S：*クォータルート受信トレイ ""
// The INBOX mailbox is covered by a single quota root with name "".
//受信トレイメールボックスは、名前 ""の単一クォータルートでカバーされています。
S: * QUOTAROOT comp.mail.mime
S：* Quotaroot Comp.Mail.Mime.
// The comp.mail.mime mailbox has no quota root associated with it, but one can be created.
// comp.mail.mimeメールボックスにはクォータルートが関連付けられていませんが、作成できます。
The OVERQUOTA response code SHOULD be returned in the tagged NO response to an APPEND/COPY/MOVE when the addition of the message(s) puts the target mailbox over any one of its quota limits.
オーバークタの応答コードは、メッセージの追加がターゲットメールボックスをそのクォータ制限のいずれかにわたって置くときに、Append / Copy / Moveへのタグ付けなしに返されるべきです。
Example 1:
例1：
C: A003 APPEND saved-messages (\Seen) {326}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 NO [OVERQUOTA] APPEND Failed
The OVERQUOTA response code MAY also be returned in an untagged NO response in the authenticated or the selected state when a mailbox exceeds soft quota. For example, such OVERQUOTA response codes might be sent as a result of an external event (e.g., Local Mail Transfer Protocol (LMTP) [RFC2033] delivery or COPY/MOVE/APPEND in another IMAP connection) that causes the currently selected mailbox to exceed soft quota. Note that such an OVERQUOTA response code might be ambiguous because it might relate to the target mailbox (as specified in COPY/MOVE/APPEND) or to the currently selected mailbox. (The EXTRA WG chose not to address this deficiency due to syntactic limitations of IMAP response codes and because such events are likely to be rare.) This form of the OVERQUOTA response codes MUST NOT be returned if there is no mailbox selected and no command in progress that adds a message to a mailbox (e.g., APPEND).
オーバークォータの応答コードは、メールボックスがソフトクォータを超えたときに、認証された状態または選択された状態でタグされていない応答でも返されることもあります。たとえば、このようなオーバークォーター応答コードは、現在選択されているメールボックスを超えるようにするために、外部イベント（LMTP）[RFC2033]配信またはコピー/移動/追加の結果として送信されることがあります。ソフトクォータそのようなオーバークォーターの応答コードは、（コピー/移動/追加で指定されているように）ターゲットメールボックスまたは現在選択されているメールボックスに関連する可能性があるため、あいまいな場合があります。（IMAP応答コードの構文上の制限によるこの不足に対処しないため、このようなイベントは稀である可能性があるため、このようなWGは選択されています。メールボックスにメッセージを追加する進行状況（追加）。
Example 2:
例2：
C: A003 APPEND saved-messages (\Seen) {326}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: * NO [OVERQUOTA] Soft quota has been exceeded
S: A003 OK [APPENDUID 38505 3955] APPEND completed
Example 3:
例3：
C: A004 COPY 2:4 MEETING
S: * NO [OVERQUOTA] Soft quota has been exceeded
S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY
command completed
The following resource types are defined in this memo. A server supporting a resource type MUST advertise this as a CAPABILITY with a name consisting of the resource name prefixed by "QUOTA=RES-". A server MAY support multiple resource types and MUST advertise all resource types it supports.
このメモには、次のリソースタイプが定義されています。リソースタイプをサポートするサーバーは、 "quota = res-"でプレフィックスされたリソース名からなる名前を持つ機能としてアドバタイズする必要があります。サーバーは複数のリソースタイプをサポートし、それがサポートするすべてのリソースタイプをアドバタイズする必要があります。
"STORAGE" is the physical space estimate, in units of 1024 octets, of the mailboxes governed by the quota root. This MAY not be the same as the sum of the RFC822.SIZE of the messages. Some implementations MAY include metadata sizes for the messages and mailboxes, and other implementations MAY store messages in such a way that the physical space used is smaller, for example, due to use of compression. Additional messages might not increase the usage. Clients MUST NOT use the usage figure for anything other than informational purposes; for example, they MUST NOT refuse to APPEND a message if the limit less the usage is smaller than the RFC822.SIZE divided by 1024 octets of the message, but it MAY warn about such condition.
「ストレージ」は、クォータルートによって管理されているメールボックスの、1024オクテット単位で、物理的な空間推定値です。これはメッセージのRFC8222.Sizeの合計と同じではない可能性があります。いくつかの実装形態は、メッセージおよびメールボックスのためのメタデータサイズを含み、他の実装形態は、例えば圧縮の使用のために、使用される物理スペースが小さいようにメッセージを記憶することができる。追加のメッセージは使用量を増やすことがないかもしれません。クライアントは、情報の目的以外のものについて使用姿を使用してはいけません。たとえば、制限がRFC822.SIZEをメッセージの1024オクテットで割った限界が小さい場合、メッセージを追加してはいけませんが、そのような条件について警告することがあります。
The usage figure may change as a result of performing actions not associated with adding new messages to the mailbox, such as SEARCH, since this may increase the amount of metadata included in the calculations.
使用量は、検索などのメールボックスに新しいメッセージを追加することに関連していないアクションを実行した結果、これが計算に含まれるメタデータの量を増やす可能性があるため、変更される可能性があります。
When the server supports this resource type, it MUST also support the DELETED-STORAGE status data item.
サーバーがこのリソースタイプをサポートするとき、それは削除されたストレージステータスデータ項目もサポートする必要があります。
Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES-STORAGE" capability.
このリソースのサポートは、 "quota = res-storage"機能を広告することによってサーバーによって示されなければなりません。
A resource named the same was also given as an example in [RFC2087]. This document provides a more precise definition.
[RFC2087]の例としても、同じリソースも示しました。この文書はより正確な定義を提供します。
"MESSAGE" is the number of messages stored within the mailboxes governed by the quota root. This MUST be an exact number; however, clients MUST NOT assume that a change in the usage indicates a change in the number of messages available, since the quota root may include mailboxes the client has no access to.
"message"は、クォータルートによって管理されているメールボックス内に格納されているメッセージの数です。これは正確な数でなければなりません。ただし、クライアントのルートにアクセスできないメールボックスには、使用可能なメッセージ数の変更が使用可能なメッセージ数の変更を示しているクライアントは、クライアントは使用可能なメッセージ数の変更を示してはいけません。
When the server supports this resource type, it MUST also support the DELETED status data item.
サーバーがこのリソースタイプをサポートすると、削除されたステータスデータ項目もサポートする必要があります。
Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES-MESSAGE" capability.
このリソースのサポートは、 "quota = res-message"機能を広告することによってサーバーによって示されなければなりません。
A resource named the same was also given as an example in [RFC2087]. This document provides a more precise definition.
[RFC2087]の例としても、同じリソースも示しました。この文書はより正確な定義を提供します。
"MAILBOX" is the number of mailboxes governed by the quota root. This MUST be an exact number; however, clients MUST NOT assume that a change in the usage indicates a change in the number of mailboxes, since the quota root may include mailboxes the client has no access to.
"mailbox"は、クォータルートによって管理されているメールボックスの数です。これは正確な数でなければなりません。ただし、クライアントのルートはメールボックスにアクセスできないメールボックスを含めることができるため、クライアントはメールボックスの数の変更を示していることを想定してはいけません。
Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES-MAILBOX" capability.
このリソースのサポートは、 "quota = res-mailbox"機能を広告することによってサーバーによって示されなければなりません。
"ANNOTATION-STORAGE" is the maximum size of all annotations [RFC5257], in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root.
"Annotation-Storage"は、クォータルートによって管理されているメールボックス内のすべてのメッセージに関連付けられている、1024オクテットの単位で、すべての注釈[RFC5257]の最大サイズです。
Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES-ANNOTATION-STORAGE" capability.
このリソースのサポートは、 "quota = res-annotation-storage"機能を広告することによってサーバーによって示されなければなりません。
This section lists [RFC4314] rights required to execute quota-related commands when both RFC 4314 and this document are implemented.
このセクションでは、RFC 4314とこのドキュメントの両方が実装されているときにクォータ関連のコマンドの実行に必要な[RFC4314]権限をリストします。
+===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
| Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non |
+===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
| GETQUOTA | | | | | | | | | | | | + |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
| GETQUOTAROOT | |*| | | | | | | | | | * |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
| SETQUOTA | | | | | | | | | | + | | |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
Table 1
表1
See Section 4 of [RFC4314] for conventions used in this table.
この表で使用されている規則については、[RFC4314]のセクション4を参照してください。
Legend:
伝説：
"+": The right is required
""右が必要です
"*": Only one of the rights marked with * is required
"Any": At least one of the "l", "r", "i", "k", "x", or "a" rights is required
「any」：「L」、「R」、「I」、「K」、「X」、または「A」権利の少なくとも1つが必要です。
"Non": No rights required to perform the command
"Non"：コマンドを実行するために必要な権利なし
Note that which permissions are needed in order to perform a GETQUOTAROOT command depends on the quota resource type being requested. For example, a quota on the number of messages (MESSAGE resource type) or total size of messages (STORAGE resource type) requires "r" right on the mailbox in question, since the quota involved would reveal information about the number (or total size) of messages in the mailbox. By comparison, the MAILBOX resource type doesn't require any right.
getquotarootコマンドを実行するために必要な権限が必要な場合は、要求されているクォータリソースタイプによって異なります。たとえば、メッセージの数（メッセージリソースタイプ）の数（メッセージリソースタイプ）またはメッセージの合計サイズ（ストレージリソースタイプ）には、関与するクォータが番号に関する情報（または合計サイズ）に関する情報が表示されるため、問題のメールボックスの「R」が必要です。メールボックス内のメッセージの。比較すると、メールボックスリソースタイプは正しくは必要ありません。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
次の構文仕様は、[ABNF]で指定されているように拡張された背景 - Naur形式（ABNF）表記を使用します。
Non-terminals referenced but not defined below are as defined by IMAP4 [RFC3501] [RFC9051].
以下に参照されたが定義されていないが、以下の非端末は、IMAP4 [RFC3501] [RFC9051]で定義されている通りである。
Except as noted otherwise, 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.
特に記載されている場合を除き、すべてのアルファベット文字は大文字と小文字が区別されません。トークン文字列を定義するための大文字または小文字の使用は、編集の明確さのみです。実装は大文字と小文字を区別しない方法でこれらの文字列を受け入れる必要があります。
getquota = "GETQUOTA" SP quota-root-name
GetQuota = "getquota" sp quot-root-name
getquotaroot = "GETQUOTAROOT" SP mailbox
GetQuotaroot = "getquotaroot" SPメールボックス
quota-list = "(" quota-resource *(SP quota-resource) ")"
quota-resource = resource-name SP resource-usage SP resource-limit
クォータ-resource = resource-name sp resource-usage sp resource-limit
quota-response = "QUOTA" SP quota-root-name SP quota-list
quota-response = "quota" sp quot-root-name sp quota-list
quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name)
quotaroot-response = "quotaroot" spメールボックス*（sp quota-root-name）
setquota = "SETQUOTA" SP quota-root-name SP setquota-list
setquota = "setquota" sp quot-root-name sp setquota-list
setquota-list = "(" [setquota-resource *(SP setquota-resource)] ")"
setquota-list = "（" [SetQuota-Resource *（SP Setquota-Resource）] "）"
setquota-resource = resource-name SP resource-limit
quota-root-name = astring
resource-limit = number64
resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" /
"ANNOTATION-STORAGE" / resource-name-ext
resource-name-ext = atom ;; Future resource registrations
resource-name-ext = atom。将来のリソース登録
resource-usage = number64 ;; must be less than corresponding resource-limit
Resource-Usage = Number64 ;;対応するリソース制限よりも小さい必要があります
capability-quota = capa-quota-res / "QUOTASET" ;; One or more capa-quota-res must be returned. ;; Also "QUOTASET" can optionally be returned.
Capability-quota = capa-quota-res / "quotaset" ;;1つ以上のcapa-quota-resを返す必要があります。;;また、「クォリセット」も任意選択で返されます。
capa-quota-res = "QUOTA=RES-" resource-name
capa-quota-res = "quota = res-"リソース名
status-att =/ "DELETED" / "DELETED-STORAGE"
;; DELETED status data item MUST be supported
;; when the "QUOTA=RES-MESSAGE" capability is
;; advertised.
;; DELETED-STORAGE status data item MUST be
;; supported when the "QUOTA=RES-STORAGE"
;; capability is advertised.
status-att-val =/ status-att-deleted / status-att-deleted-storage
status-att-val = / status-att-att-deleted / status-att-deleted-storage
status-att-deleted = "DELETED" SP number
;; DELETED status data item MUST be supported
;; when the "QUOTA=RES-MESSAGE" capability is
;; advertised.
status-att-deleted-storage = "DELETED-STORAGE" SP number64
;; DELETED-STORAGE status data item MUST be
;; supported when the "QUOTA=RES-STORAGE"
;; capability is advertised.
resp-text-code =/ "OVERQUOTA"
レステキストコード= /「オーバーコータ」
number64 = <Defined in RFC 9051>
Implementors should be careful to make sure the implementation of these commands does not violate the site's security policy. The resource usage of other users is likely to be considered confidential information and should not be divulged to unauthorized persons. In particular, no quota information should be disclosed to anonymous users.
これらのコマンドの実装がサイトのセキュリティポリシーに違反していないことを確認するように注意してください。他のユーザーのリソース使用量は機密情報と見なされる可能性があり、不正な人に分割されるべきではありません。特に、クォータ情報は匿名ユーザーに開示されるべきではありません。
As for any resource shared across users (for example, a quota root attached to a set of shared mailboxes), a user that can consume or render unusable the resource can affect the resources available to the other users; this might occur, for example, by a user with permission to execute the SETQUOTA setting, which sets an artificially small value.
ユーザー間で共有されているリソース（たとえば、共有メールボックスのセットに添付されているクォータルートなど）は、使用できないユーザーが他のユーザーが利用できるリソースに影響を与える可能性があります。これは、例えば、人工的に小さい値を設定するSetQuota設定を実行する許可を有するユーザによって発生する可能性がある。
Note that computing resource usage might incur a heavy load on the server. Server implementers should consider implementation techniques that lower the load on servers such as caching of resource usage information or usage of less precise computations when under heavy load.
コンピューティングリソース使用量がサーバー上の重い負荷をかける可能性があることに注意してください。サーバー実装者は、リソース使用状況情報のキャッシングや、重い負荷の下にあるときの正確な計算の使用などのサーバーの負荷を軽減する実装技術を検討する必要があります。
IMAP4 capabilities are registered by publishing a Standards Track or an IESG-approved Informational or Experimental RFC. The "IMAP Capabilities" registry is currently located at <https://www.iana.org/assignments/imap4-capabilities>.
IMAP4機能は、標準トラックまたはIESG承認済みの情報または実験的RFCを公開することによって登録されています。"IMAP機能"レジストリは現在<https://www.iana.org/ashignments/imap4-capabilities>にあります。
IANA has updated the reference for the QUOTA extension to point to this document. IANA has also added the "QUOTA=" prefix and the "QUOTASET" capability to the "IMAP Capabilities" registry with this document as the reference.
この文書を指すために、IANAはクォータ拡張の参照を更新しました。IANAは、このドキュメントを参照として、 "quota ="プレフィックスと "quotaset"機能を "IMAP機能"レジストリに追加しました。
IANA has added the following notes to the "IMAP Capabilities" registry:
IANAには、「IMAP機能」レジストリに次の注意事項を追加しました。
The prefix "QUOTA=RES-" is reserved per RFC 9208, Section 9.1. See Section 9.2 of that document for values that follow this prefix.
Prefix "quota = res-"はRFC 9208で予約されています。この接頭辞に続く値については、そのドキュメントの9.2項を参照してください。
All other capabilities starting with the "QUOTA=" prefix are reserved for future IETF Stream extensions to RFC 9208.
"quota ="接頭辞から始まる他のすべての機能は、RFC 9208への将来のIETF Stream Extensionsのために予約されています。
IANA has created a new registry for IMAP quota resource types. The registration policy for the "IMAP Quota Resource Types" registry is "Specification Required" [RFC8126].
IANAはIMAPクォータリソースタイプの新しいレジストリを作成しました。「IMAPクォータリソースタイプ」レジストリの登録ポリシーは、「指定必須」[RFC8126]です。
When registering a new quota resource type, the registrant needs to provide the following:
新しいクォータリソースタイプを登録するとき、登録者は次のように入力する必要があります。
* the name of the quota resource type
* クォータリソースタイプの名前
* a short description
* 簡単な説明
* extra required IMAP commands/responses (if any)
* 追加の必須IMAPコマンド/応答（ある場合）
* extra optional IMAP commands/responses (if any)
* 追加のオプションのIMAPコマンド/応答（ある場合）
* name and email address of author
* 著者の名前と電子メールアドレス
* name and email address of change controller
* 変更コントローラの名前とEメールアドレス
* a reference to a specification that describes the quota resource type in more detail
* クォータリソースタイプをより詳細に説明する仕様への参照
Designated experts should check that the provided references are correct, the references describe the quota resource type being registered in sufficient detail to be implementable, the syntax of any optional commands/responses is correct (e.g., ABNF validates), and the syntax/description complies with rules and limitations imposed by IMAP [RFC3501] [RFC9051]. Designated experts should avoid registering multiple identical quota resource types under different names and should provide advice to requestors about other possible quota resource types to use.
指定された専門家は、提供された参照が正しいことを確認する必要があります。参照可能なクォータリソースタイプは、実装可能に登録されているクォータリソースタイプで、オプションのコマンド/応答の構文が正しい（ABNFの検証）、構文/説明に準拠しています。IMAP [RFC3501] [RFC9051]によって課された規則と制限により。指定された専門家は、異なる名前で複数の同一のクォータリソースタイプを登録することを避けるべきであり、使用する他の可能なクォータリソースタイプについて要求者にアドバイスを提供する必要があります。
The initial contents of the "IMAP Quota Resource Types" registry are as follows:
「IMAPクォータリソースタイプ」レジストリの初期内容は次のとおりです。
+===================+=======================================+
| field name | field value |
+===================+=======================================+
| Name of the quota | STORAGE |
| resource type: | |
+-------------------+---------------------------------------+
| Description: | The physical space estimate, in units |
| | of 1024 octets, of the mailboxes |
| | governed by the quota root. |
+-------------------+---------------------------------------+
| Extra required | DELETED-STORAGE STATUS request data |
| IMAP commands/ | item and response data item |
| responses: | |
+-------------------+---------------------------------------+
| Extra optional | N/A |
| IMAP commands/ | |
| responses: | |
+-------------------+---------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+-------------------+---------------------------------------+
| Change | IESG <iesg@ietf.org> |
| Controller: | |
+-------------------+---------------------------------------+
| Reference: | Section 5.1 of RFC 9208 |
+-------------------+---------------------------------------+
Table 2: STORAGE
表2：ストレージ
+=====================+==========================================+
| field name | field value |
+=====================+==========================================+
| Name of the quota | MESSAGE |
| resource type: | |
+---------------------+------------------------------------------+
| Description: | The number of messages stored within the |
| | mailboxes governed by the quota root. |
+---------------------+------------------------------------------+
| Extra required IMAP | DELETED STATUS request data item and |
| commands/responses: | response data item |
+---------------------+------------------------------------------+
| Extra optional IMAP | N/A |
| commands/responses: | |
+---------------------+------------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+---------------------+------------------------------------------+
| Change Controller: | IESG <iesg@ietf.org> |
+---------------------+------------------------------------------+
| Reference: | Section 5.2 of RFC 9208 |
+---------------------+------------------------------------------+
Table 3: MESSAGE
表3：メッセージ
+==================================+=============================+
| field name | field value |
+==================================+=============================+
| Name of the quota resource type: | MAILBOX |
+----------------------------------+-----------------------------+
| Description: | The number of mailboxes |
| | governed by the quota root. |
+----------------------------------+-----------------------------+
| Extra required IMAP commands/ | N/A |
| responses: | |
+----------------------------------+-----------------------------+
| Extra optional IMAP commands/ | N/A |
| responses: | |
+----------------------------------+-----------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+----------------------------------+-----------------------------+
| Change Controller: | IESG <iesg@ietf.org> |
+----------------------------------+-----------------------------+
| Reference: | Section 5.3 of RFC 9208 |
+----------------------------------+-----------------------------+
Table 4: MAILBOX
表4：メールボックス
+================+=======================================+
| field name | field value |
+================+=======================================+
| Name of the | ANNOTATION-STORAGE |
| quota resource | |
| type: | |
+----------------+---------------------------------------+
| Description: | The maximum size of all annotations |
| | [RFC5257], in units of 1024 octets, |
| | associated with all messages in the |
| | mailboxes governed by the quota root. |
+----------------+---------------------------------------+
| Extra required | N/A |
| IMAP commands/ | |
| responses: | |
+----------------+---------------------------------------+
| Extra optional | N/A |
| IMAP commands/ | |
| responses: | |
+----------------+---------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+----------------+---------------------------------------+
| Change | IESG <iesg@ietf.org> |
| Controller: | |
+----------------+---------------------------------------+
| Reference: | Section 5.4 of RFC 9208 |
+----------------+---------------------------------------+
Table 5: ANNOTATION-STORAGE
表5：注釈記憶域
This document is a revision of [RFC2087], and it aims to clarify the meaning of different terms that were used in that RFC. It also provides more examples, gives guidance on allowed server behavior, defines an IANA registry for quota resource types, and provides initial registrations for 4 of them.
この文書は[RFC2087]の改訂であり、そのRFCで使用されたさまざまな用語の意味を明確にすることを目的としています。それはより多くの例を提供し、許可されたサーバーの動作に関するガイダンスを提供し、クォータリソースタイプのためのIANAレジストリを定義し、それらの4つのための最初の登録を提供します。
When compared with [RFC2087], this document defines two more commonly used resource types, adds an optional OVERQUOTA response code, and defines two extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The DELETED STATUS data item must be implemented if the "QUOTA=RES-MESSAGE" capability is advertised. The DELETED-STORAGE STATUS data item must be implemented if the "QUOTA=RES-STORAGE" capability is advertised. For extensibility, quota usage and quota limits are now 63-bit unsigned integers.
[RFC2087]と比較すると、このドキュメントは2つの一般的に使用されているリソースタイプを定義し、オプションのオーバークォーターの応答コードを追加し、2つの追加のステータスデータ項目（「削除済み」と「削除済み」）を定義します。"quota = res-message"機能が広告されている場合、削除されたステータスデータ項目を実装する必要があります。"quota = res-storage"機能がアドバタイズされている場合、削除されたストレージステータスデータ項目を実装する必要があります。拡張性のために、クォータの使用量とクォータの制限は63ビットの符号なし整数です。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[ABNF] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc5234、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc5234,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/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, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3501]クリスピン、M、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<https：//www.rfc-editor.org/info/rfc3501>。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005, <https://www.rfc-editor.org/info/rfc4314>.
[RFC4314]メルニコフ、A。、「IMAP4アクセス制御リスト（ACL）拡張」、RFC 4314、DOI 10.17487 / RFC4314、2005年12月、<https：//www.rfc-editor.org/info/rfc4314>。
[RFC5257] Daboo, C. and R. Gellens, "Internet Message Access Protocol - ANNOTATE Extension", RFC 5257, DOI 10.17487/RFC5257, June 2008, <https://www.rfc-editor.org/info/rfc5257>.
[RFC5257] Daboo、CおよびR.Gellens、「インターネットメッセージアクセスプロトコル - アノテート拡張」、RFC 5257、DOI 10.17487 / RFC5257、2008年6月、<https：//www.rfc-editor.org/info/rfc5257>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, <https://www.rfc-editor.org/info/rfc9051>.
[RFC9051]メルニコフ、A.、ED。B. Leiba、Ed。、「Internet Message Access Protocol（IMAP） - バージョン4Rev2」、RFC 9051、DOI 10.17487 / RFC9051、8月2021日、<https：//www.rfc-editor.org/info/rfc9051>。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, DOI 10.17487/RFC2033, October 1996, <https://www.rfc-editor.org/info/rfc2033>.
[RFC2033]マイヤーズ、J.、「ローカルメール転送プロトコル」、RFC 2033、DOI 10.17487 / RFC2033、1996年10月、<https：//www.rfc-editor.org/info/rfc2033>。
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, DOI 10.17487/RFC2087, January 1997, <https://www.rfc-editor.org/info/rfc2087>.
[RFC2087]マイヤーズ、J.、「IMAP4クォータ拡張」、RFC 2087、DOI 10.17487 / RFC2087、1997年1月、<https：//www.rfc-editor.org/info/rfc2087>。
[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, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
Acknowledgments
謝辞
The editor of this document would like to thank the following people who provided useful comments or participated in discussions that lead to this update of [RFC2087]: John Myers, Cyrus Daboo, Lyndon Nerenberg, Benjamin Kaduk, Roman Danyliw, and Éric Vyncke.
この文書の編集者は、「RFC2087」のこのアップデートにつながる、議論に参加した次の人々に感謝します。
This document is a revision of [RFC2087], and it borrows a lot of text from that RFC. Thus, the work of John Myers, the author of [RFC2087], is appreciated.
この文書は[RFC2087]のリビジョンであり、そのRFCからのテキストがたくさん借りています。したがって、John Myersの仕事、RFC2087]の作者が理解されています。
Contributors
貢献者
Dave Cridland wrote a lot of text in an earlier draft version that became the basis for this document.
Dave Cridlandは、この文書の基礎となった以前のドラフトバージョンで多くのテキストを書いた。
Author's Address
作者の住所
Alexey Melnikov
Isode Limited
Email: alexey.melnikov@isode.com
URI: https://www.isode.com