draft-ietf-extra-quota-08.txt		draft-ietf-extra-quota-09.txt
	Network Working Group A. Melnikov		Network Working Group A. Melnikov
	Internet-Draft Isode		Internet-Draft Isode
	Obsoletes: 2087 (if approved) 21 October 2021		Obsoletes: 2087 (if approved) 22 October 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 24 April 2022		Expires: 25 April 2022
	IMAP QUOTA Extension		IMAP QUOTA Extension
	draft-ietf-extra-quota-08		draft-ietf-extra-quota-09
	Abstract		Abstract
	This document defines a QUOTA extension of the Internet Message		This document defines a QUOTA extension of the Internet Message
	Access Protocol (RFC 3501/RFC 9051) that permits administrative		Access Protocol (RFC 3501/RFC 9051) that permits administrative
	limits on resource usage (quotas) to be manipulated through the IMAP		limits on resource usage (quotas) to be manipulated through the IMAP
	protocol.		protocol.
	This document obsoletes RFC 2087, but attempts to remain backwards		This document obsoletes RFC 2087, but attempts to remain backwards
	compatible whenever possible.		compatible whenever possible.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 24 April 2022.		This Internet-Draft will expire on 25 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10		4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10		4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10
	4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 11		4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 11
	5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12		5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12
	5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13		5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13
	6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14		6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14
	7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14		7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Changes/additions to the IMAP4 capabilities registry . . 17		9.1. Changes/additions to the IMAP4 capabilities registry . . 17
	9.2. IMAP quota resource type registry . . . . . . . . . . . . 17		9.2. IMAP quota resource type registry . . . . . . . . . . . . 18
	9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18		9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19		12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 20
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	13.1. Normative References . . . . . . . . . . . . . . . . . . 20		13.1. Normative References . . . . . . . . . . . . . . . . . . 20
	13.2. Informative References . . . . . . . . . . . . . . . . . 20		13.2. Informative References . . . . . . . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Document Conventions		1. Document Conventions
	In protocol examples, this document uses a prefix of "C: " to denote		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		lines sent by the client to the server, and "S: " for lines sent by
	the server to the client. Lines prefixed with "// " are comments		the server to the client. Lines prefixed with "// " are comments
	explaining the previous protocol line. These prefixes and comments		explaining the previous protocol line. These prefixes and comments
	are not part of the protocol. Lines without any of these prefixes		are not part of the protocol. Lines without any of these prefixes
	are continuations of the previous line, and no line break is present		are continuations of the previous line, and no line break is present
	in the protocol unless specifically mentioned.		in the protocol before such lines unless specifically mentioned.
	Again, for examples, the hierarchy separator on the IMAP server is
	presumed to be "/" throughout. None of these assumptions is required
	nor recommended by this document.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Other capitalised words are IMAP keywords [RFC3501][RFC9051] or		Other capitalised words are IMAP keywords [RFC3501][RFC9051] or
	keywords from this document.		keywords from this document.
	skipping to change at page 6, line 44 ¶		skipping to change at page 6, line 33 ¶
	Result: OK - getquota completed		Result: OK - getquota completed
	NO - getquota error: no such quota root, permission denied		NO - getquota error: no such quota root, permission denied
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	The GETQUOTA command takes the name of a quota root and returns the		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.		quota root's resource usage and limits in an untagged QUOTA response.
	(Names of quota roots applicable to a particular mailbox can be		(Names of quota roots applicable to a particular mailbox can be
	discovered by issuing the GETQUOTAROOT command, see Section 4.1.2.)		discovered by issuing the GETQUOTAROOT command, see Section 4.1.2.)
	The client can try using any of the resource types returned in		Note that the server is not required to support any specific resource
	CAPABILITY response (i.e. all capability items with "QUOTA=RES-"		type (as advertised in the CAPABILITY response, i.e. all capability
	prefix), however the server is not required to support any specific		items with the "QUOTA=RES-" prefix) for any particular quota root.
	resource type for any particular quota root.
	Example:		Example:
	S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...]		S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...]
	[...]		[...]
	C: G0001 GETQUOTA "!partition/sda4"		C: G0001 GETQUOTA "!partition/sda4"
	S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)		S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
	skipping to change at page 8, line 23 ¶		skipping to change at page 8, line 15 ¶
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	Note that unlike other command/responses/response codes defined in		Note that unlike other command/responses/response codes defined in
	this document, support for SETQUOTA command requires the server to		this document, support for SETQUOTA command requires the server to
	advertise "QUOTASET" capability.		advertise "QUOTASET" capability.
	The SETQUOTA command takes the name of a mailbox quota root and a		The SETQUOTA command takes the name of a mailbox quota root and a
	list of resource limits. The resource limits for the named quota		list of resource limits. The resource limits for the named quota
	root are changed to be the specified limits. Any previous resource		root are changed to be the specified limits. Any previous resource
	limits for the named quota root are discarded.		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.)
	If the named quota root did not previously exist, an implementation		If the named quota root did not previously exist, an implementation
	may optionally create it and change the quota roots for any number of		may optionally create it and change the quota roots for any number of
	existing mailboxes in an implementation-defined manner.		existing mailboxes in an implementation-defined manner.
	If the implementation chooses to change the quota roots for some		If the implementation chooses to change the quota roots for some
	existing mailboxes such changes SHOULD be announced with untagged		existing mailboxes such changes SHOULD be announced with untagged
	QUOTA responses.		QUOTA responses.
	Example:		Example:
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 40 ¶
	4.2.2. QUOTAROOT		4.2.2. QUOTAROOT
	Data: mailbox name		Data: mailbox name
	zero or more quota root names		zero or more quota root names
	This response occurs as a result of a GETQUOTAROOT command. The		This response occurs as a result of a GETQUOTAROOT command. The
	first string is the mailbox and the remaining strings are the names		first string is the mailbox and the remaining strings are the names
	of the quota roots for the mailbox.		of the quota roots for the mailbox.
	Example:		Examples:
	S: * QUOTAROOT INBOX ""		S: * QUOTAROOT INBOX ""
			// 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.
	4.3. Response Codes		4.3. Response Codes
	4.3.1. OVERQUOTA		4.3.1. OVERQUOTA
	OVERQUOTA response code SHOULD be returned in the tagged NO response		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		to an APPEND/COPY/MOVE when the addition of the message(s) puts the
	target mailbox over any one of its quota limits.		target mailbox over any one of its quota limits.
	Example 1: C: A003 APPEND saved-messages (\Seen) {326}		Example 1: C: A003 APPEND saved-messages (\Seen) {326}
	S: + Ready for literal data		S: + Ready for literal data
	C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)		C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
	skipping to change at page 14, line 35 ¶		skipping to change at page 14, line 35 ¶
	+ - The right is required		+ - The right is required
	* - Only one of the rights marked with * is required		* - Only one of the rights marked with * is required
	"Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is		"Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
	required		required
	"Non" - no rights required to perform the command		"Non" - no rights required to perform the command
			Note that which permissions are needed in order to perform
			GETQUOTAROOT command depends on the quota resource type being
			requested. For example, a quota on 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.
	7. Formal syntax		7. Formal syntax
	The following syntax specification uses the Augmented Backus-Naur		The following syntax specification uses the Augmented Backus-Naur
	Form (ABNF) notation as specified in [ABNF].		Form (ABNF) notation as specified in [ABNF].
	Non-terminals referenced but not defined below are as defined by		Non-terminals referenced but not defined below are as defined by
	IMAP4 [RFC3501].		IMAP4 [RFC3501].
	Except as noted otherwise, all alphabetic characters are case-		Except as noted otherwise, all alphabetic characters are case-
	insensitive. The use of upper or lower case characters to define		insensitive. The use of upper or lower case characters to define
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 15 ¶
	8. Security Considerations		8. Security Considerations
	Implementors should be careful to make sure the implementation of		Implementors should be careful to make sure the implementation of
	these commands does not violate the site's security policy. The		these commands does not violate the site's security policy. The
	resource usage of other users is likely to be considered confidential		resource usage of other users is likely to be considered confidential
	information and should not be divulged to unauthorized persons. In		information and should not be divulged to unauthorized persons. In
	particular, no quota information should be disclosed to anonymous		particular, no quota information should be disclosed to anonymous
	users.		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 SETQUOTA setting an artificially small value.
	Note that computing resource usage might incur a heavy load on the		Note that computing resource usage might incur a heavy load on the
	server. Server implementers should consider implementation		server. Server implementers should consider implementation
	techniques that lower load on servers, such as caching of resource		techniques that lower load on servers, such as caching of resource
	usage information or usage of less precise computations when under		usage information or usage of less precise computations when under
	heavy load.		heavy load.
	9. IANA Considerations		9. IANA Considerations
	9.1. Changes/additions to the IMAP4 capabilities registry		9.1. Changes/additions to the IMAP4 capabilities registry
End of changes. 16 change blocks.
	21 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/