draft-ietf-extra-quota-01.txt		draft-ietf-extra-quota-02.txt
	Network Working Group A. Melnikov		Network Working Group A. Melnikov
	Internet-Draft Isode		Internet-Draft Isode
	Intended status: Standards Track June 15, 2020		Intended status: Standards Track July 1, 2020
	Expires: December 17, 2020		Expires: January 2, 2021
	IMAP QUOTA Extension		IMAP QUOTA Extension
	draft-ietf-extra-quota-01		draft-ietf-extra-quota-02
	Abstract		Abstract
	The QUOTA extension of the Internet Message Access Protocol (RFC		The QUOTA extension of the Internet Message Access Protocol (RFC
	3501) permits administrative limits on resource usage (quotas) to be		3501) permits administrative limits on resource usage (quotas) to be
	manipulated through the IMAP protocol.		manipulated through the IMAP protocol.
	This memo obsoletes RFC 2087, but attempts to remain backwards		This memo obsoletes RFC 2087, but attempts to remain backwards
	compatible whenever possible.		compatible whenever possible.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 December 17, 2020.		This Internet-Draft will expire on January 2, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	Table of Contents		Table of Contents
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6		4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6
	4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6		4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6
	4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7		4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7
	4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 8		4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 8
	4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9		4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 9		4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 9
	4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 9		4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 9
	5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 10		5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 11
	5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12		5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12
	6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12		6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12
	7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Registrations of IMAP Quota Resource Types . . . . . . . 14		9.1. Registrations of IMAP Quota Resource Types . . . . . . . 15
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15		10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
	12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 16		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		13. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 16
	13.1. Normative References . . . . . . . . . . . . . . . . . . 16		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	13.2. Informative References . . . . . . . . . . . . . . . . . 17		14.1. Normative References . . . . . . . . . . . . . . . . . . 17
			14.2. Informative References . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	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
	skipping to change at page 3, line 34 ¶		skipping to change at page 3, line 35 ¶
	"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 [RFC2119] 8174 [RFC8174] when, and only when, they appear		14 RFC2119 [RFC2119] 8174 [RFC8174] when, and only when, they appear
	in all capitals, as shown here.		in all capitals, as shown here.
	Other capitalised words are IMAP4 [RFC3501] keywords or keywords from		Other capitalised words are IMAP4 [RFC3501] keywords or keywords from
	this document.		this document.
	2. Introduction and Overview		2. Introduction and Overview
			This document defines a couple of extension to the Internet Message
			Access Protocol [RFC3501] for querying and manipulating
			administrative limits on resource usage (quotas).
	The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server.		The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server.
	Some commands and responses defined in this document are not present		Some responses and response codes defined in this document are not
	in such servers, and clients MUST NOT rely on their presence in the		present in such servers (see Section 13 for more details), and
	absence of any capability beginning with "QUOTA=".		clients MUST NOT rely on their presence in the absence of any
			capability beginning with "QUOTA=".
	Any server compliant with this document MUST also return at least one		Any server compliant with this document MUST also return at least one
	capability starting with "QUOTA=RES-" prefix, as described in		capability starting with "QUOTA=RES-" prefix, as described in
	Section 3.1.		Section 3.1.
			Any server compliant with this document that implements the SETQUOTA
			command (see Section 4.1.3) MUST also return the "QUOTASET"
			capability.
	This document also reserves all other capabilities starting with		This document also reserves all other capabilities starting with
	"QUOTA=" prefix to future standard track or experimental extensions		"QUOTA=" prefix for future IETF stream standard track or experimental
	to this document.		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		dependant, 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
	skipping to change at page 4, line 50 ¶		skipping to change at page 5, line 11 ¶
	Limits will be specified as, and MUST be represented as, an integer.		Limits will be specified as, and MUST be represented as, an integer.
	0 indicates that any usage is prohibited.		0 indicates that any usage is prohibited.
	Limits may be hard or soft - that is, an implementation MAY choose,		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		or be configured, to disallow any command if the limit on a resource
	is or would be exceeded.		is or would be exceeded.
	All resources which the server handles must be advertised in a		All resources which the server handles must be advertised in a
	CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-".		CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-".
	For compatability with RFC2087 [RFC2087], a client which discovers		For compatability with RFC 2087 [RFC2087], a client which discovers
	resources available on the server which are not advertised through		resources available on the server which are not advertised through
	this mechanism MUST treat them as if they were completely opaque, and		this mechanism MUST treat them as if they were completely opaque, and
	without any meaning.		without any meaning.
	The resources STORAGE (Section 5.1), MESSAGE (Section 5.2) and		The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX
	MAILBOX (Section 5.3) are defined in this document.		(Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in
			this document.
	3.2. Quota Root		3.2. Quota Root
	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 memo between a Quota root name and a		relationship defined by this memo between a Quota root name and a
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 43 ¶
	S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)		S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
	S: G0001 OK Getquota complete		S: G0001 OK Getquota complete
	4.1.2. GETQUOTAROOT		4.1.2. GETQUOTAROOT
	Arguments: mailbox name		Arguments: mailbox name
	Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA		Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA
	Result: OK - getquotaroot completed		Result: OK - getquotaroot completed
	NO - getquotaroot error: no such mailbox, permission denied		NO - getquotaroot error: permission denied
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	The GETQUOTAROOT command takes a mailbox name and returns the list of		The GETQUOTAROOT command takes a mailbox name and returns the list of
	quota roots for the mailbox in an untagged QUOTAROOT response. For		quota roots for the mailbox in an untagged QUOTAROOT response. For
	each listed quota root, it also returns the quota root's resource		each listed quota root, it also returns the quota root's resource
	usage and limits in an untagged QUOTA response.		usage and limits in an untagged QUOTA response.
	Note that the mailbox name parameter doesn't have to reference an		Note that the mailbox name parameter doesn't have to reference an
	existing mailbox. This can be handy in order to determine which		existing mailbox. This can be handy in order to determine which
	quotaroot would apply to a mailbox when it gets created.		quotaroot would apply to a mailbox when it gets created.
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 32 ¶
	Arguments: quota root		Arguments: quota root
	list of resource limits		list of resource limits
	Responses: untagged responses: QUOTA		Responses: untagged responses: QUOTA
	Result: OK - setquota completed		Result: OK - setquota completed
	NO - setquota error: can't set that data		NO - setquota error: can't set that data
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
			Note that unlike other command/responses/response codes defined in
			this document, support for SETQUOTA command requires the server to
			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.
	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:
	S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE		S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES-
	[...]		MESSAGE [...]
	[...]		[...]
	C: S0000 GETQUOTA "#user/alice"		C: S0000 GETQUOTA "#user/alice"
	S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000)		S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000)
	S: S0000 OK Getquota completed		S: S0000 OK Getquota completed
	C: S0001 SETQUOTA "#user/alice" (STORAGE 510)		C: S0001 SETQUOTA "#user/alice" (STORAGE 510)
	S: * QUOTA "#user/alice" (STORAGE 58 512)		S: * QUOTA "#user/alice" (STORAGE 58 512)
	// The server has rounded the STORAGE quota limit requested to the		// The server has rounded the STORAGE quota limit requested to the
	nearest 512 blocks of 1024 octects, or else another client has		nearest 512 blocks of 1024 octects, or else another client has
	performed a near simultaneous SETQUOTA, using a limit of 512.		performed a near simultaneous SETQUOTA, using a limit of 512.
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 28 ¶
	S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)		S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
	// The server has not changed the quota, since this is a		// The server has not changed the quota, since this is a
	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-MESSAGES and DELETED-STORAGE status data items allow to		DELETED and DELETED-STORAGE status data items allow to estimate the
	estimate the amount of resource freed by an EXPUNGE on a mailbox.		amount of resource freed by an EXPUNGE on a mailbox.
	DELETED-MESSAGES status data item requests the server to return the		DELETED status data item requests the server to return the number of
	number of messages with \Deleted flag set.		messages with \Deleted flag set.
	DELETED-STORAGE status data item requests the server to return the		DELETED-STORAGE status data item requests the server to return the
	amount of storage space that can be reclaimed by performing EXPUNGE		amount of storage space that can be reclaimed by performing EXPUNGE
	on the mailbox. The server SHOULD return the exact value, however it		on the mailbox. The server SHOULD return the exact value, however it
	is recognized that the server may have to do non-trivial amount of		is recognized that the server may have to do non-trivial amount of
	work to calculate it. If the calculation of the exact value would		work to calculate it. If the calculation of the exact value would
	take a long time, the server MAY instead return the sum of		take a long time, the server MAY instead return the sum of
	RFC822.SIZEs of messages with the \Deleted flag set.		RFC822.SIZEs of messages with the \Deleted flag set.
	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-MESSAGES DELETED-STORAGE)		C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
	S: * STATUS INBOX (MESSAGES 12 DELETED-MESSAGES 4 DELETED-STORAGE		S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
	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.
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 36 ¶
	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.
	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]. In absence of information to the contrary, clients		[RFC2087]. This document provides a more precise definition.
	conformant to this specification connecting to servers which do not
	advertise "QUOTA=RES-STORAGE", yet allow a resource named STORAGE,
	MUST NOT assume that it is the same resource. [[CREF1: Is the above
	restriction useful and will it be obeyed? If the answer is "no",
	delete it.]]
	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.
	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], clients conformant to this specification connecting to		[RFC2087]. This document provides a more precise definition.
	servers which do not advertise "QUOTA=RES-MESSAGE", yet allow a
	resource named MESSAGE, MUST NOT assume that it is the same resource.
	[[CREF2: As above.]]
	5.3. MAILBOX		5.3. MAILBOX
	The number of mailboxes governed by the quota root. This MUST be an		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		exact number, however, clients MUST NOT assume that a change in the
	usage indicates a change in the number of mailboxes, since the quota		usage indicates a change in the number of mailboxes, since the quota
	root may include mailboxes the client has no access to.		root may include mailboxes the client has no access to.
	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-MAILBOX".		advertising the CAPABILITY "QUOTA=RES-MAILBOX".
	5.4. ANNOTATION-STORAGE		5.4. ANNOTATION-STORAGE
	[[CREF3: Bron to check whether this is a sensible description and		[[CREF1: Bron to check whether this is a sensible description and
	whether it is needed at all:]] The maximum size of all annotations		whether it is needed at all:]] The maximum size of all annotations
	[RFC5257], in units of 1024 octets, associated with all messages in		[RFC5257], in units of 1024 octets, associated with all messages in
	the mailboxes governed by the quota root.		the mailboxes governed by the quota root.
	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-ANNOTATION-STORAGE".		advertising the CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE".
	6. Interaction with IMAP ACL extension (RFC 4314)		6. Interaction with IMAP ACL extension (RFC 4314)
	[[CREF4: TBD]]		This section lists [RFC4314] rights required to execute quota related
			commands when both RFC 4314 and this document are implemented.
			+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
			| Operations\Ri | l | r | s | w | i | c | x | t | e | a | Any | Non |
			| ghts | | | | | | | | | | | | |
			+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
			| GETQUOTA | | | | | | | | | | | | * |
			| GETQUOTAROOT | | * | | | | | | | | | | * |
			| SETQUOTA | | | | | | | | | | + | | |
			+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
			See Section 4 of RFC 4314 for conventions used in this table.
			[[CREF2: The above table needs to be reviewed based on feedback from
			existing and planned implementations.]]
	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-
	skipping to change at page 13, line 15 ¶		skipping to change at page 13, line 32 ¶
	setquota = "SETQUOTA" SP quota-root-name SP setquota-list		setquota = "SETQUOTA" SP quota-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		setquota-resource = resource-name SP resource-limit
	quota-root-name = astring		quota-root-name = astring
	resource-limit = number		resource-limit = number64
	resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" /		resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" /
	resource-name-vnd /		"ANNOTATION-STORAGE" / resource-name-vnd /
	resource-name-ext		resource-name-ext
	resource-name-vnd = "V-" atom		resource-name-vnd = "V-" atom
	;; Vendor specific, must be registered with IANA.		;; Vendor specific, must be registered with IANA.
	;; 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 a Standard Track or Experimental RFC
	resource-names = "(" [resource-name *(SP resource-name)] ")"		resource-names = "(" [resource-name *(SP resource-name)] ")"
	resource-usage = number		resource-usage = number64
	;; must be less than corresponding resource-limit		;; must be less than corresponding resource-limit
	capability-quota = capa-quota-res		capability-quota = capa-quota-res / "QUOTASET"
			;; One or more capa-quota-res must be returned.
			;; Also "QUOTASET" can optionally be returned.
	capa-quota-res = "QUOTA=RES-" resource-name		capa-quota-res = "QUOTA=RES-" resource-name
	status-att =/ "DELETED-MESSAGES" / "DELETED-STORAGE"		status-att =/ "DELETED" / "DELETED-STORAGE"
	[[CREF5: Should the above be optional unless the		status-att-val =/ ("DELETED" SP number) /
	server implements MESSAGE/STORAGE? Also sync		("DELETED-STORAGE" SP number64)
	this with IMAP4rev2.]]
	resp-text-code =/ "OVERQUOTA" [SP tag]		resp-text-code =/ "OVERQUOTA" [SP tag]
			number64 = 1*DIGIT ;; Unsigned 63-bit integer.
			;; (0 <= n <= 9,223,372,036,854,775,807)
	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.		information and should not be divulged to unauthorized persons.
	9. IANA Considerations		9. IANA Considerations
	IMAP4 capabilities are registered by publishing a standards track or		IMAP4 capabilities are registered by publishing a standards track or
	skipping to change at page 14, line 38 ¶		skipping to change at page 15, line 7 ¶
	description and a reference to a specification that describes the		description and a reference to a specification that describes the
	quota resource type in more details.		quota resource type in more details.
	This document includes initial registrations for the following IMAP		This document includes initial registrations for the following IMAP
	quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2),		quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2),
	MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See		MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See
	details below.		details below.
	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 quote resource type registry established above.		IMAP quota resource type registry established above.
	IANA is requested to reserve all other capabilities starting with		IANA is requested to reserve all other capabilities starting with
	"QUOTA=" prefix for future standard track or experimental extensions		"QUOTA=" prefix for future IETF stream standard track or experimental
	to this document.		extensions to this document.
	9.1. Registrations of IMAP Quota Resource Types		9.1. Registrations of IMAP Quota Resource Types
	Name of the quota resource type: STORAGE		Name of the quota resource type: STORAGE
	Author: Alexey Melnikov <alexey.melnikov@isode.com>		Author: Alexey Melnikov <alexey.melnikov@isode.com>
	Change Controller: IESG <iesg@ietf.org>		Change Controller: IESG <iesg@ietf.org>
	Description: The physical space estimate, in units of 1024 octets,		Description: The physical space estimate, in units of 1024 octets,
	of the mailboxes governed by the quota root.		of the mailboxes governed by the quota root.
	Reference: Section 5.1 of RFCXXXX		Reference: Section 5.1 of RFCXXXX
	Name of the quota resource type: MESSAGE		Name of the quota resource type: MESSAGE
	Author: Alexey Melnikov <alexey.melnikov@isode.com>		Author: Alexey Melnikov <alexey.melnikov@isode.com>
	Change Controller: IESG <iesg@ietf.org>		Change Controller: IESG <iesg@ietf.org>
	skipping to change at page 15, line 35 ¶		skipping to change at page 16, line 4 ¶
	Description: The number of mailboxes governed by the quota root.		Description: The number of mailboxes governed by the quota root.
	Reference: Section 5.3 of RFCXXXX		Reference: Section 5.3 of RFCXXXX
	Name of the quota resource type:		Name of the quota resource type:
	Author: Alexey Melnikov <alexey.melnikov@isode.com>		Author: Alexey Melnikov <alexey.melnikov@isode.com>
	Change Controller: IESG <iesg@ietf.org>		Change Controller: IESG <iesg@ietf.org>
	Description: The maximum size of all annotations [RFC5257], in units		Description: The maximum size of all annotations [RFC5257], in units
	of 1024 octets, associated with all messages in the mailboxes		of 1024 octets, associated with all messages in the mailboxes
	governed by the quota root. [[CREF6: Recheck against the final		governed by the quota root. [[CREF3: Recheck against the final
	description of "ANNOTATION-STORAGE".]]		description of "ANNOTATION-STORAGE".]]
	Reference: Section 5.4 of RFCXXXX		Reference: Section 5.4 of RFCXXXX
	10. Contributors		10. Open Issues
			'"OVERQUOTA" SP tag' form has syntactic issues, as "tag" allows for
			"]", which is not allowed in response codes. Should we drop this
			variant or change IMAP4rev2 to disallow "]" in tags?
			Should "DELETED" status item be required to be implemented for
			anything other than QUOTA-RES=MESSAGE? Similarly, should "DELETED-
			STORAGE" status item be required to be implemented for anything other
			than QUOTA-RES=STORAGE?
			11. 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		12. Acknowledgments
	Editors of this document would like to thank the following people who		Editors 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:		this update to RFC 2087:
	John Myers,		John Myers,
	Cyrus Daboo,		Cyrus Daboo,
	Lyndon Nerenberg		Lyndon Nerenberg
	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		13. Changes since RFC 2087
	This document is a revision of RFC 2087. It tries to clarify meaning		This document is a revision of RFC 2087. It tries to clarify meaning
	of different terms used by RFC 2087. It also provides more examples,		of different terms used by RFC 2087. It also provides more examples,
	gives guidance on allowed server behaviour, defines IANA registry for		gives guidance on allowed server behaviour, defines IANA registry for
	quota resource types and provides initial registrations for 3 of		quota resource types and provides initial registrations for 3 of
	them.		them.
	When compared with RFC 2087, this document defines one 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-MESSAGES" and "DELETED-		two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that
	STORAGE")		must be implemented. For extensibility quota usage and quota limits
			are now 63 bit unsigned integers.
	13. References		14. References
	13.1. Normative References		14.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.
	[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
	skipping to change at page 17, line 14 ¶		skipping to change at page 17, line 36 ¶
	[RFC5257] Daboo, C. and R. Gellens, "Internet Message Access		[RFC5257] Daboo, C. and R. Gellens, "Internet Message Access
	Protocol - ANNOTATE Extension", RFC 5257,		Protocol - ANNOTATE Extension", RFC 5257,
	DOI 10.17487/RFC5257, June 2008,		DOI 10.17487/RFC5257, June 2008,
	<https://www.rfc-editor.org/info/rfc5257>.		<https://www.rfc-editor.org/info/rfc5257>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	13.2. Informative References		14.2. Informative References
	[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,		[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
	DOI 10.17487/RFC2087, January 1997,		DOI 10.17487/RFC2087, January 1997,
	<https://www.rfc-editor.org/info/rfc2087>.		<https://www.rfc-editor.org/info/rfc2087>.
	Author's Address		Author's Address
	Alexey Melnikov		Alexey Melnikov
	Isode Limited		Isode Limited
End of changes. 43 change blocks.
	68 lines changed or deleted		106 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/