< draft-ietf-extra-quota-07.txt		draft-ietf-extra-quota-08.txt >
	Network Working Group A. Melnikov		Network Working Group A. Melnikov
	Internet-Draft Isode		Internet-Draft Isode
	Obsoletes: 2087 (if approved) 24 September 2021		Obsoletes: 2087 (if approved) 21 October 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 28 March 2022		Expires: 24 April 2022
	IMAP QUOTA Extension		IMAP QUOTA Extension
	draft-ietf-extra-quota-07		draft-ietf-extra-quota-08
	Abstract		Abstract
	The QUOTA extension of the Internet Message Access Protocol (RFC		This document defines a QUOTA extension of the Internet Message
	3501/RFC 9051) permits administrative limits on resource usage		Access Protocol (RFC 3501/RFC 9051) that permits administrative
	(quotas) to be manipulated through the IMAP protocol.		limits on resource usage (quotas) to be manipulated through the IMAP
			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.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 28 March 2022.		This Internet-Draft will expire on 24 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 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3		1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3		2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
	3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4		3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6		4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6
	4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6		4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 7
	4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7		4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7
	4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9		4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9
	4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10		4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10		4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10
	4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10		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 . . . . . . . . . . . . . . . . . . . . . . . . . 12		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) . . . . . . . 13		6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14
	7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14		7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Changes/additions to the IMAP4 capabilities registry . . 16		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 . . . . . . . . . . . . 17
	9.3. Registrations of IMAP Quota Resource Types . . . . . . . 17		9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19		12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	13.1. Normative References . . . . . . . . . . . . . . . . . . 19		13.1. Normative References . . . . . . . . . . . . . . . . . . 20
	13.2. Informative References . . . . . . . . . . . . . . . . . 20		13.2. Informative References . . . . . . . . . . . . . . . . . 20
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
	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
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	"QUOTA=" prefix for future IETF stream standard track, informational		"QUOTA=" prefix for future IETF stream standard track, informational
	or experimental extensions to this document.		or experimental extensions to this document.
	Quotas can be used to restrict clients for administrative reasons,		Quotas can be used to restrict clients for administrative reasons,
	but the QUOTA extension can also be used to indicate system limits		but the QUOTA extension can also be used to indicate system limits
	and current usage levels to clients.		and current usage levels to clients.
	Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and		Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and
	this has seen deployment in servers, it has seen little deployment in		this has seen deployment in servers, it has seen little deployment in
	clients. Since the meaning of the resources was left implementation-		clients. Since the meaning of the resources was left implementation-
	dependant, it was impossible for a client implementation to determine		dependent, it was impossible for a client implementation to determine
	which resources were supported, and impossible to determine which		which resources were supported, and impossible to determine which
	mailboxes were in a given quota root (see Section 3.2), without a		mailboxes were in a given quota root (see Section 3.2), without a
	priori knowledge of the implementation.		priori knowledge of the implementation.
	3. Terms		3. Terms
	3.1. Resource		3.1. Resource
	A resource has a name, a formal definition.		A resource has a name, a formal definition.
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	All resources which the server handles MUST be advertised in a		All resources which the server handles MUST be advertised in a
	CAPABILITY response/response code consisting of the resource name		CAPABILITY response/response code consisting of the resource name
	prefixed by "QUOTA=RES-".		prefixed by "QUOTA=RES-".
	The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX		The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX
	(Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in		(Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in
	this document.		this document.
	3.2. Quota Root		3.2. Quota Root
			This document introduces a concept of a "quota root", as resource
			limits can apply across multiple IMAP mailboxes.
	Each mailbox has zero or more implementation-defined named "quota		Each mailbox has zero or more implementation-defined named "quota
	roots". Each quota root has zero or more resource limits (quotas).		roots". Each quota root has zero or more resource limits (quotas).
	All mailboxes that share the same named quota root share the resource		All mailboxes that share the same named quota root share the resource
	limits of the quota root.		limits of the quota root.
	Quota root names need not be mailbox names, nor is there any		Quota root names need not be mailbox names, nor is there any
	relationship defined by this document between a quota root name and a		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		mailbox name. A quota root name is an astring, as defined in IMAP4
	[RFC3501]. It SHOULD be treated as an opaque string by any clients.		[RFC3501]. It SHOULD be treated as an opaque string by any clients.
	Quota roots are used since not all implementations may be able to		Quota roots are used since not all implementations may be able to
	calculate usage, or apply quotas, on arbitary mailboxes or mailbox		calculate usage, or apply quotas, on arbitrary mailboxes or mailbox
	hierarchies.		hierarchies.
	Not all resources may be limitable or calculatable for all quota		Not all resources may be limitable or calculable for all quota roots.
	roots. Further, not all resources may support all limits - some		Further, not all resources may support all limits - some limits may
	limits may be present in the underlying system. A server		be present in the underlying system. A server implementation of this
	implementation of this memo SHOULD advise the client of such inherent		memo SHOULD advise the client of such inherent limits, by generating
	limits, by generating QUOTA (Section 4.2.1) responses and SHOULD		QUOTA (Section 4.2.1) responses, and SHOULD advise the client of
	advise the client of which resources are limitable for a particular		which resources are limitable for a particular quota root. A
	quota root. A SETQUOTA (Section 4.1.3) command MAY also round a		SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an
	quota limit in an implementation dependant way, if the granularity of		implementation-dependent way, if the granularity of the underlying
	the underlying system demands it. A client MUST be prepared for a		system demands it. A client MUST be prepared for a SETQUOTA
	SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set.		(Section 4.1.3) command to fail if a limit cannot be set.
	Implementation Notes: This means that, for example under UNIX, a		Implementation Notes: This means that, for example under UNIX, a
	quota root may have a MESSAGE (Section 5.2) quota always set due to		quota root may have a MESSAGE (Section 5.2) quota always set due to
	the number of inodes available on the filesystem, and similarly		the number of inodes available on the filesystem, and similarly
	STORAGE (Section 5.1) may be rounded to the nearest block and limited		STORAGE (Section 5.1) may be rounded to the nearest block and limited
	by free filesystem space.		by free filesystem space.
	4. Definitions		4. Definitions
	4.1. Commands		4.1. Commands
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 42 ¶
	Responses: REQUIRED untagged responses: QUOTA		Responses: REQUIRED untagged responses: QUOTA
	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
			discovered by issuing the GETQUOTAROOT command, see Section 4.1.2.)
	The client can try using any of the resource types returned in		The client can try using any of the resource types returned in
	CAPABILITY response (i.e. all capability items with "QUOTA=RES-"		CAPABILITY response (i.e. all capability items with "QUOTA=RES-"
	prefix), however the server is not required to support any specific		prefix), however the server is not required to support any specific
	resource type 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 [...]
	[...]		[...]
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 25 ¶
	filesystem limit, and cannot be changed. The QUOTA response here		filesystem limit, and cannot be changed. The QUOTA response here
	is entirely optional.		is entirely optional.
	S: S0002 NO Cannot change system limit		S: S0002 NO Cannot change system limit
	4.1.4. New STATUS attributes		4.1.4. New STATUS attributes
	DELETED and DELETED-STORAGE status data items allow to estimate the		DELETED and DELETED-STORAGE status data items allow to estimate the
	amount of resource freed by an EXPUNGE on a mailbox.		amount of resource freed by an EXPUNGE on a mailbox.
	DELETED status data item requests the server to return the number of		The DELETED status data item requests the server to return the number
	messages with \Deleted flag set. DELETED status data item is only		of messages with \Deleted flag set. The DELETED status data item is
	required to be implemented when the server advertises QUOTA=RES-		only required to be implemented when the server advertises QUOTA=RES-
	MESSAGE capability.		MESSAGE capability.
	DELETED-STORAGE status data item requests the server to return the		The DELETED-STORAGE status data item requests the server to return
	amount of storage space that can be reclaimed by performing EXPUNGE		the amount of storage space that can be reclaimed by performing
	on the mailbox. The server SHOULD return the exact value, however it		EXPUNGE on the mailbox. The server SHOULD return the exact value,
	is recognized that the server may have to do non-trivial amount of		however it is recognized that the server may have to do non-trivial
	work to calculate it. If the calculation of the exact value would		amount of work to calculate it. If the calculation of the exact
	take a long time, the server MAY instead return the sum of		value would take a long time, the server MAY instead return the sum
	RFC822.SIZEs of messages with the \Deleted flag set. DELETED-STORAGE		of RFC822.SIZEs of messages with the \Deleted flag set. The DELETED-
	status data item is only required to be implemented when the server		STORAGE status data item is only required to be implemented when the
	advertises QUOTA=RES-STORAGE capability.		server advertises QUOTA=RES-STORAGE capability.
	Example:		Example:
	S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE		S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
	[...]		[...]
	[...]		[...]
	C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)		C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
	skipping to change at page 9, line 37 ¶		skipping to change at page 10, line 4 ¶
	Example:		Example:
	S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE		S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
	[...]		[...]
	[...]		[...]
	C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)		C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
	S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)		S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
	// 12 messages, 4 of which would be deleted when an EXPUNGE		// 12 messages, 4 of which would be deleted when an EXPUNGE
	happens.		happens.
	S: S0003 OK Status complete.		S: S0003 OK Status complete.
	4.2. Responses		4.2. Responses
	The following responses may be sent by the server.		The following responses may be sent by the server.
	4.2.1. QUOTA		4.2.1. QUOTA
	Data: quota root name		Data: quota root name
	list of resource names, usages, and limits		list of resource names, usages, and limits
	This response occurs as a result of a GETQUOTA or GETQUOTAROOT		This response occurs as a result of a GETQUOTA, a GETQUOTAROOT or a
	command. The first string is the name of the quota root for which		SETQUOTA command. The first string is the name of the quota root for
	this quota applies.		which this quota applies.
	The name is followed by a S-expression format list of the resource		The name is followed by a S-expression format list of the resource
	usage and limits of the quota root. The list contains zero or more		usage and limits of the quota root. The list contains zero or more
	triplets. Each triplet contains a resource name, the current usage		triplets. Each triplet contains a resource name, the current usage
	of the resource, and the resource limit.		of the resource, and the resource limit.
	Resources not named in the list are not limited in the quota root.		Resources not named in the list are not limited in the quota root.
	Thus, an empty list means there are no administrative resource limits		Thus, an empty list means there are no administrative resource limits
	in the quota root.		in the quota root.
	skipping to change at page 11, line 49 ¶		skipping to change at page 12, line 20 ¶
	C: To: mooch@owatagu.siam.edu.example		C: To: mooch@owatagu.siam.edu.example
	C: Message-Id: <B27397-0100000@Blurdybloop.example>		C: Message-Id: <B27397-0100000@Blurdybloop.example>
	C: MIME-Version: 1.0		C: MIME-Version: 1.0
	C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII		C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
	C:		C:
	C: Hello Joe, do you think we can meet at 3:30 tomorrow?		C: Hello Joe, do you think we can meet at 3:30 tomorrow?
	C:		C:
	S: * NO [OVERQUOTA] Soft quota has been exceeded		S: * NO [OVERQUOTA] Soft quota has been exceeded
	S: A003 OK [APPENDUID 38505 3955] APPEND completed		S: A003 OK [APPENDUID 38505 3955] APPEND completed
	Example 3: C: A003 COPY 2:4 MEETING		Example 3: C: A004 COPY 2:4 MEETING
	S: * NO [OVERQUOTA] Soft quota has been exceeded		S: * NO [OVERQUOTA] Soft quota has been exceeded
	S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY		S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY
	command completed		command completed
	5. Resource Type Definitions		5. Resource Type Definitions
	The following resource types are defined in this memo. A server		The following resource types are defined in this memo. A server
	supporting a resource type MUST advertise this as a CAPABILITY with a		supporting a resource type MUST advertise this as a CAPABILITY with a
	name consisting of the resource name prefixed by "QUOTA=RES-". A		name consisting of the resource name prefixed by "QUOTA=RES-". A
	server MAY support multiple resource types, and MUST advertise all		server MAY support multiple resource types, and MUST advertise all
	resource types it supports.		resource types it supports.
	skipping to change at page 12, line 32 ¶		skipping to change at page 13, line 5 ¶
	use the usage figure for anything other than informational purposes,		use the usage figure for anything other than informational purposes,
	for example, they MUST NOT refuse to APPEND a message if the limit		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 of the		less the usage is smaller than the RFC822.SIZE divided by 1024 of the
	message, but it MAY warn about such condition.		message, but it MAY warn about such condition.
	The usage figure may change as a result of performing actions not		The usage figure may change as a result of performing actions not
	associated with adding new messages to the mailbox, such as SEARCH,		associated with adding new messages to the mailbox, such as SEARCH,
	since this may increase the amount of metadata included in the		since this may increase the amount of metadata included in the
	calculations.		calculations.
	When the server supports this resource type, it MUST also support		When the server supports this resource type, it MUST also support the
	DELETED-STORAGE status data item.		DELETED-STORAGE status data item.
	Support for this resource MUST be indicated by the server by		Support for this resource MUST be indicated by the server by
	advertising the CAPABILITY "QUOTA=RES-STORAGE".		advertising the CAPABILITY "QUOTA=RES-STORAGE".
	A resource named the same was also given as an example in RFC2087		A resource named the same was also given as an example in RFC2087
	[RFC2087]. This document provides a more precise definition.		[RFC2087]. This document provides a more precise definition.
	5.2. MESSAGE		5.2. MESSAGE
	The number of messages stored within the mailboxes governed by the		The number of messages stored within the mailboxes governed by the
	quota root. This MUST be an exact number, however, clients MUST NOT		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		assume that a change in the usage indicates a change in the number of
	messages available, since the quota root may include mailboxes the		messages available, since the quota root may include mailboxes the
	client has no access to.		client has no access to.
	When the server supports this resource type, it MUST also support		When the server supports this resource type, it MUST also support the
	DELETED status data item.		DELETED status data item.
	Support for this resource MUST be indicated by the server by		Support for this resource MUST be indicated by the server by
	advertising the CAPABILITY "QUOTA=RES-MESSAGE".		advertising the CAPABILITY "QUOTA=RES-MESSAGE".
	A resource named the same was also given as an example in RFC2087		A resource named the same was also given as an example in RFC2087
	[RFC2087]. This document provides a more precise definition.		[RFC2087]. This document provides a more precise definition.
	5.3. MAILBOX		5.3. MAILBOX
	skipping to change at page 15, line 18 ¶		skipping to change at page 15, line 40 ¶
	;; The "V-" prefix should be followed by a domain		;; The "V-" prefix should be followed by a domain
	name		name
	;; under vendor's control.		;; under vendor's control.
	resource-name-ext = atom		resource-name-ext = atom
	;; Not starting with V- and defined		;; Not starting with V- and defined
	;; in a Standard Track or Experimental RFC		;; in an IETF Stream RFC
	resource-names = "(" [resource-name *(SP resource-name)] ")"
	resource-usage = number64		resource-usage = number64
	;; must be less than corresponding resource-limit		;; must be less than corresponding resource-limit
	capability-quota = capa-quota-res / "QUOTASET"		capability-quota = capa-quota-res / "QUOTASET"
	;; One or more capa-quota-res must be returned.		;; One or more capa-quota-res must be returned.
	;; Also "QUOTASET" can optionally be returned.		;; Also "QUOTASET" can optionally be returned.
	skipping to change at page 15, line 52 ¶		skipping to change at page 16, line 25 ¶
	;; DELETED-STORAGE status data item MUST be		;; DELETED-STORAGE status data item MUST be
	;; supported when "QUOTA=RES-STORAGE" capability		;; supported when "QUOTA=RES-STORAGE" capability
	;; is advertised.		;; is advertised.
	status-att-val =/ status-att-deleted /		status-att-val =/ status-att-deleted /
	status-att-deleted-storage		status-att-deleted-storage
	status-att-deleted =/ "DELETED" SP number		status-att-deleted = "DELETED" SP number
	;; DELETED status data item MUST be supported		;; DELETED status data item MUST be supported
	;; when "QUOTA=RES-MESSAGE" capability is		;; when "QUOTA=RES-MESSAGE" capability is
	;; advertised.		;; advertised.
	status-att-deleted-storage =/ "DELETED-STORAGE" SP number64		status-att-deleted-storage = "DELETED-STORAGE" SP number64
	;; DELETED-STORAGE status data item MUST be		;; DELETED-STORAGE status data item MUST be
	;; supported when "QUOTA=RES-STORAGE" capability		;; supported when "QUOTA=RES-STORAGE" capability
	;; is advertised.		;; is advertised.
	resp-text-code =/ "OVERQUOTA"		resp-text-code =/ "OVERQUOTA"
	number64 = <Defined in RFC 9051>		number64 = <Defined in RFC 9051>
	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.
			Note that computing resource usage might incur a heavy load on the
			server. Server implementers should consider implementation
			techniques that lower load on servers, such as caching of resource
			usage information or usage of less precise computations when under
			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
	IMAP4 capabilities are registered by publishing a standards track or		IMAP4 capabilities are registered by publishing a standards track or
	IESG approved Informational or Experimental RFC. The registry is		IESG approved Informational or Experimental RFC. The registry is
	currently located at:		currently located at:
	http://www.iana.org/assignments/imap4-capabilities		https://www.iana.org/assignments/imap4-capabilities
	IANA is requested to update definition of the QUOTA extension to		IANA is requested to update definition of the QUOTA extension to
	point to this document. IANA is also requested to add the "QUOTASET"		point to this document. IANA is also requested to add the "QUOTASET"
	capability to the IMAP4 capabilities registry, with this document as		capability to the IMAP4 capabilities registry, with this document as
	the reference.		the reference.
	IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4		IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4
	capabilities registry and add a pointer to this document and to the		capabilities registry and add a pointer to this document and to the
	IMAP quota resource type registry (see Section 9.2).		IMAP quota resource type registry (see Section 9.2).
	IANA is requested to reserve all other capabilities starting with		IANA is requested to reserve all other capabilities starting with
	"QUOTA=" prefix for future IETF stream standard track, informational		"QUOTA=" prefix for future IETF Stream extensions to this document.
	or experimental extensions to this document.
	9.2. IMAP quota resource type registry		9.2. IMAP quota resource type registry
	IANA is requested to create a new registry for IMAP quota resource		IANA is requested to create a new registry for IMAP quota resource
	types. Registration policy for this registry is "Specification		types. Registration policy for this registry is "Specification
	Required". When registering a new quota resource type, the		Required". When registering a new quota resource type, the
	registrant need to provide the following: Name of the quota resource		registrant need to provide the following: Name of the quota resource
	type, Author/Change Controller name and email address, short		type, Author/Change Controller name and email address, short
	description, extra (if any) required and optional IMAP commands/		description, extra (if any) required and optional IMAP commands/
	responses, and a reference to a specification that describes the		responses, and a reference to a specification that describes the
	skipping to change at page 19, line 14 ¶		skipping to change at page 19, line 33 ¶
	10. Contributors		10. Contributors
	Dave Cridland wrote lots of text in an earlier draft that became the		Dave Cridland wrote lots of text in an earlier draft that became the
	basis for this document.		basis for this document.
	11. Acknowledgments		11. Acknowledgments
	Editor of this document would like to thank the following people who		Editor of this document would like to thank the following people who
	provided useful comments or participated in discussions that lead to		provided useful comments or participated in discussions that lead to
	this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg.		this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg,
			Benjamin Kaduk, Roman Danyliw, Eric Vyncke.
	This document is a revision of RFC 2087. It borrows a lot of text		This document is a revision of RFC 2087. It borrows a lot of text
	from RFC 2087. Thus work of the RFC 2087 author John Myers is		from RFC 2087. Thus work of the RFC 2087 author John Myers is
	appreciated.		appreciated.
	12. Changes since RFC 2087		12. Changes since RFC 2087
	This document is a revision of RFC 2087. It tries to clarify the		This document is a revision of RFC 2087. It tries to clarify the
	meaning of different terms used by RFC 2087. It also provides more		meaning of different terms used by RFC 2087. It also provides more
	examples, gives guidance on allowed server behaviour, defines IANA		examples, gives guidance on allowed server behaviour, defines IANA
	registry for quota resource types and provides initial registrations		registry for quota resource types and provides initial registrations
	for 4 of them.		for 4 of them.
	When compared with RFC 2087, this document defines two more commonly		When compared with RFC 2087, this document defines two more commonly
	used resource type, adds optional OVERQUOTA response code and defines		used resource type, adds optional OVERQUOTA response code and defines
	two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that		two extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The
	must be implemented. For extensibility quota usage and quota limits		DELETED STATUS data item must be implemented if the QUOTA=RES-MESSAGE
	are now 63 bit unsigned integers.		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.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for		[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for
	Syntax Specifications: ABNF", RFC 5234, January 2008,		Syntax Specifications: ABNF", RFC 5234, January 2008,
	<ftp://ftp.isi.edu/in-notes/rfc5234.txt>.		<https://www.rfc-editor.org/info/rfc5234>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,		4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
	<https://www.rfc-editor.org/info/rfc3501>.		<https://www.rfc-editor.org/info/rfc3501>.
End of changes. 35 change blocks.
	63 lines changed or deleted		76 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/