draft-ietf-extra-quota-00.txt		draft-ietf-extra-quota-01.txt
	Network Working Group A. Melnikov		Network Working Group A. Melnikov
	Internet-Draft Isode		Internet-Draft Isode
	Intended status: Standards Track June 17, 2019		Intended status: Standards Track June 15, 2020
	Expires: December 19, 2019		Expires: December 17, 2020
	IMAP QUOTA Extension		IMAP QUOTA Extension
	draft-ietf-extra-quota-00		draft-ietf-extra-quota-01
	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 19, 2019.		This Internet-Draft will expire on December 17, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . . . . . . 10
	5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 11		5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	11. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 14		9.1. Registrations of IMAP Quota Resource Types . . . . . . . 14
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
	12.1. Normative References . . . . . . . . . . . . . . . . . . 14		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	12.2. Informative References . . . . . . . . . . . . . . . . . 15		12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 16
			13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		13.1. Normative References . . . . . . . . . . . . . . . . . . 16
			13.2. Informative References . . . . . . . . . . . . . . . . . 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
	in the protocol unless specifically mentioned.		in the protocol unless specifically mentioned.
	Again, for examples, the hierarchy separator on the server is		Again, for examples, the hierarchy separator on the server is
	presumed to be "/" throughout. None of these assumptions is required		presumed to be "/" throughout. None of these assumptions is required
	nor recommended by this document.		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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 RFC2119 [RFC2119] 8174 [RFC8174] when, and only when, they appear
			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
	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 commands and responses defined in this document are not present
	in such servers, and clients MUST NOT rely on their presence in the		in such servers, and clients MUST NOT rely on their presence in the
	absence of any capability beginning with "QUOTA=".		absence of any capability beginning with "QUOTA=".
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 21 ¶
	the implementation.		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.
	3.1.1. Name		3.1.1. Name
	[[CREF1: Fix IANA considerations section.]]		The resource name is an atom, as defined in IMAP4rev1 [RFC3501].
			These MUST be registered with IANA. Implementation specific
	The resource name is an atom, as defined in IMAP4 [RFC3501]. These		resources begin with "V-" .
	MUST be registered with IANA. Implementation specific resources
	begin with "V-" .
	Supported resource names MUST be advertised as a capability, by		Supported resource names MUST be advertised as a capability, by
	prepending the resource name with "QUOTA=RES-". A server compliant		prepending the resource name with "QUOTA=RES-". A server compliant
	with this specification is not required to support all reported		with this specification is not required to support all reported
	resource types on all quota roots.		resource types on all quota roots.
	3.1.2. Definition		3.1.2. Definition
	The resource definition or document containing it, while not visible		The resource definition or document containing it, while not visible
	through the protocol, SHOULD be registered with IANA.		through the protocol, SHOULD be registered with IANA.
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 40 ¶
	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: no such mailbox, permission denied
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	The GETQUOTAROOT command takes the name of a mailbox and returns the		The GETQUOTAROOT command takes a mailbox name and returns the list of
	list of quota roots for the mailbox in an untagged QUOTAROOT		quota roots for the mailbox in an untagged QUOTAROOT response. For
	response. For each listed quota root, it also returns the quota		each listed quota root, it also returns the quota root's resource
	root's resource usage and limits in an untagged QUOTA response.		usage and limits in an untagged QUOTA response.
	[[CREF2: Need to clarify that the mailbox name doesn't have to		Note that the mailbox name parameter doesn't have to reference an
	reference an existing mailbox. This can be handy in order to		existing mailbox. This can be handy in order to determine which
	determine which quotaroot would apply to a mailbox when it gets		quotaroot would apply to a mailbox when it gets created.
	created.]]
	Example:		Example:
	S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE		S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
	[...]		[...]
	[...]		[...]
	C: G0002 GETQUOTAROOT INBOX		C: G0002 GETQUOTAROOT INBOX
	S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4"		S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4"
	S: * QUOTA "#user/alice" (MESSAGE 42 1000)		S: * QUOTA "#user/alice" (MESSAGE 42 1000)
	S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)		S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
	S: G0002 OK Getquotaroot complete		S: G0002 OK Getquotaroot complete
	4.1.3. SETQUOTA		4.1.3. SETQUOTA
	Arguments: quota root		Arguments: quota root
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 33 ¶
	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.
	[[CREF3: Should the server be sending untagged QUOTA responses for		If the implementation chooses to change the quota roots for some
	all side effect changes?]]		existing mailboxes such changes SHOULD be announced with untagged
			QUOTA responses.
	Example:		Example:
	S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE		S: * CAPABILITY [...] QUOTA 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)
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 40 ¶
	S: * QUOTAROOT INBOX ""		S: * QUOTAROOT INBOX ""
	S: * QUOTAROOT comp.mail.mime		S: * QUOTAROOT comp.mail.mime
	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 when the addition of the message(s) puts mailbox		to an APPEND/COPY/MOVE when the addition of the message(s) puts the
	over any one of its quota limits.		target mailbox over any one of its quota limits.
	Example:		Example:
	S: C: A003 APPEND Drafts (\Seen $MDNSent) {310}		S: C: A003 APPEND Drafts (\Seen $MDNSent) {310}
	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)
	C: From: Fred Foobar <foobar@Blurdybloop.COM>		C: From: Fred Foobar <foobar@Blurdybloop.COM>
	C: Subject: afternoon meeting		C: Subject: afternoon meeting
	C: To: mooch@owatagu.siam.edu		C: To: mooch@owatagu.siam.edu
	C: Message-Id: <B27397-0100000@Blurdybloop.COM>		C: Message-Id: <B27397-0100000@Blurdybloop.COM>
	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: A003 NO [OVERQUOTA] APPEND Failed		S: A003 NO [OVERQUOTA] APPEND Failed
	The OVERQUOTA response code MAY also be returned in an untagged NO		The OVERQUOTA response code MAY also be returned in an untagged NO
	response when the currently selected mailbox exceeds soft quota.		response when a mailbox exceeds soft quota. Such responses have 2
	[[CREF4: What about per-user quotas when no mailbox is selected or		forms. If it is followed by a tag, the tag refers to the command
	when the destination mailbox (different from the currently selected		that caused this (such as APPEND or COPY) and the OVERQUOTA response
	one) is affected?]] The response code MUST be followed by the tag of		code applies to the target mailbox specified by such command. If the
	the command that caused this (such as APPEND or COPY). The tag MUST		OVERQUOTA response code is not followed by the tag, this means that
	be omitted if an external event (e.g. LMTP delivery or APPEND/COPY		an external event (e.g. LMTP delivery or APPEND/COPY in another IMAP
	in another IMAP connection) caused this event.		connection) caused this event and the event applies to the currently
			selected mailbox. In particular, this means that such OVERQUOTA
			response codes MUST NOT be returned if there is no mailbox selected
			or if a mailbox other than the currently selected one exceeds soft
			quota.
	Example:		Example:
	S: C: A003 APPEND Drafts (\Seen $MDNSent) {310}		S: C: A003 APPEND Drafts (\Seen $MDNSent) {310}
	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)
	C: From: Fred Foobar <foobar@Blurdybloop.COM>		C: From: Fred Foobar <foobar@Blurdybloop.COM>
	C: Subject: afternoon meeting		C: Subject: afternoon meeting
	C: To: mooch@owatagu.siam.edu		C: To: mooch@owatagu.siam.edu
	C: Message-Id: <B27397-0100000@Blurdybloop.COM>		C: Message-Id: <B27397-0100000@Blurdybloop.COM>
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 28 ¶
	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], clients conformant to this specification connecting to		[RFC2087]. In absence of information to the contrary, clients
	servers which do not advertise "QUOTA=RES-STORAGE", yet allow a		conformant to this specification connecting to servers which do not
	resource named STORAGE, MUST NOT assume that it is the same resource.		advertise "QUOTA=RES-STORAGE", yet allow a resource named STORAGE,
	[[CREF5: ?]]		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], clients conformant to this specification connecting to
	servers which do not advertise "QUOTA=RES-MESSAGE", yet allow a		servers which do not advertise "QUOTA=RES-MESSAGE", yet allow a
	resource named MESSAGE, MUST NOT assume that it is the same resource.		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".
	6. Formal syntax		5.4. ANNOTATION-STORAGE
			[[CREF3: Bron to check whether this is a sensible description and
			whether it is needed at all:]] The maximum size of all annotations
			[RFC5257], in units of 1024 octets, associated with all messages in
			the mailboxes governed by the quota root.
			Support for this resource MUST be indicated by the server by
			advertising the CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE".
			6. Interaction with IMAP ACL extension (RFC 4314)
			[[CREF4: TBD]]
			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
	token strings is for editorial clarity only. Implementations MUST		token strings is for editorial clarity only. Implementations MUST
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 42 ¶
	resource-usage = number		resource-usage = number
	;; must be less than corresponding resource-limit		;; must be less than corresponding resource-limit
	capability-quota = capa-quota-res		capability-quota = capa-quota-res
	capa-quota-res = "QUOTA=RES-" resource-name		capa-quota-res = "QUOTA=RES-" resource-name
	status-att =/ "DELETED-MESSAGES" / "DELETED-STORAGE"		status-att =/ "DELETED-MESSAGES" / "DELETED-STORAGE"
	[[CREF6: Should this be optional unless the		[[CREF5: Should the above be optional unless the
	server implements MESSAGE/STORAGE?]]		server implements MESSAGE/STORAGE? Also sync
			this with IMAP4rev2.]]
	resp-text-code =/ "OVERQUOTA" [SP tag]		resp-text-code =/ "OVERQUOTA" [SP tag]
	7. 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.
	8. 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
	IESG approved experimental RFC. The registry is currently located		IESG approved experimental RFC. The registry is currently located
	at:		at:
	http://www.iana.org/assignments/imap4-capabilities		http://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.		point to this document.
	IANA is also requested to create a new registry for IMAP quota		IANA is also requested to create a new registry for IMAP quota
	resource types. Registration policy for this registry is		resource types. Registration policy for this registry is
	"Specification Required". When registering a new quota resource		"Specification Required". When registering a new quota resource
	type, the registrant need to provide the following: Name of the quota		type, the registrant need to provide the following: Name of the quota
	resource type, Author/Change Controller name and email address, short		resource type, Author/Change Controller name and email address, short
	description and a reference to the specification.		description and a reference to a specification that describes the
			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) and		quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2),
	MAILBOX (Section 5.3).		MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See
			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 quote 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 to future standard track or experimental extensions		"QUOTA=" prefix for future standard track or experimental extensions
	to this document.		to this document.
	9. Contributors		9.1. Registrations of IMAP Quota Resource Types
			Name of the quota resource type: STORAGE
			Author: Alexey Melnikov <alexey.melnikov@isode.com>
			Change Controller: IESG <iesg@ietf.org>
			Description: The physical space estimate, in units of 1024 octets,
			of the mailboxes governed by the quota root.
			Reference: Section 5.1 of RFCXXXX
			Name of the quota resource type: MESSAGE
			Author: Alexey Melnikov <alexey.melnikov@isode.com>
			Change Controller: IESG <iesg@ietf.org>
			Description: The number of messages stored within the mailboxes
			governed by the quota root.
			Reference: Section 5.2 of RFCXXXX
			Name of the quota resource type: MAILBOX
			Author: Alexey Melnikov <alexey.melnikov@isode.com>
			Change Controller: IESG <iesg@ietf.org>
			Description: The number of mailboxes governed by the quota root.
			Reference: Section 5.3 of RFCXXXX
			Name of the quota resource type:
			Author: Alexey Melnikov <alexey.melnikov@isode.com>
			Change Controller: IESG <iesg@ietf.org>
			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. [[CREF6: Recheck against the final
			description of "ANNOTATION-STORAGE".]]
			Reference: Section 5.4 of RFCXXXX
			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
	base for this document.		basis for this document.
	10. Acknowledgments		11. 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.
	11. Changes since RFC 2087		12. 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 one 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-MESSAGES" and "DELETED-
	STORAGE")		STORAGE")
	12. References		13. References
	12.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 4234, October 2005.		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
	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>.
	12.2. Informative References		[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
			RFC 4314, DOI 10.17487/RFC4314, December 2005,
			<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>.
			[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>.
			13.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. 32 change blocks.
	66 lines changed or deleted		152 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/