draft-ietf-extra-quota-03.txt   draft-ietf-extra-quota-04.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Internet-Draft Isode
Intended status: Standards Track November 17, 2020 Intended status: Standards Track February 22, 2021
Expires: May 21, 2021 Expires: August 26, 2021
IMAP QUOTA Extension IMAP QUOTA Extension
draft-ietf-extra-quota-03 draft-ietf-extra-quota-04
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 May 21, 2021. This Internet-Draft will expire on August 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 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 41 skipping to change at page 2, line 41
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 . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10
5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 11 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 11
5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Registrations of IMAP Quota Resource Types . . . . . . . 15 9.1. Registrations of IMAP Quota Resource Types . . . . . . . 16
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 17
13. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
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 IMAP 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", "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 This document defines a couple of extension to the Internet Message
Access Protocol [RFC3501] for querying and manipulating Access Protocol [RFC3501] for querying and manipulating
administrative limits on resource usage (quotas). administrative limits on resource usage (quotas). This extension is
compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 (draft-ietf-
extra-imap4rev2)
The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server.
Some responses and response codes defined in this document are not Some responses and response codes defined in this document are not
present in such servers (see Section 13 for more details), and present in such servers (see Section 12 for more details), and
clients MUST NOT rely on their presence in the absence of any clients MUST NOT rely on their presence in the absence of any
capability beginning with "QUOTA=". 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 Any server compliant with this document that implements the SETQUOTA
command (see Section 4.1.3) MUST also return the "QUOTASET" command (see Section 4.1.3) MUST also return the "QUOTASET"
capability. capability.
This document also reserves all other capabilities starting with This document also reserves all other capabilities starting with
"QUOTA=" prefix for future IETF stream standard track or experimental "QUOTA=" prefix for future IETF stream standard track, informational
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 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 10, line 13 skipping to change at page 10, line 13
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/MOVE when the addition of the message(s) puts the to an APPEND/COPY/MOVE when the addition of the message(s) puts the
target mailbox over any one of its quota limits. target mailbox over any one of its quota limits.
Example: Example 2: C: A003 APPEND saved-messages (\Seen) {326}
S: + Ready for literal data
S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
S: + Ready for literal data C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: Subject: afternoon meeting
C: From: Fred Foobar <foobar@Blurdybloop.COM> C: To: mooch@owatagu.siam.edu.example
C: Subject: afternoon meeting C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: To: mooch@owatagu.siam.edu C: MIME-Version: 1.0
C: Message-Id: <B27397-0100000@Blurdybloop.COM> C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C: MIME-Version: 1.0 C:
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow? S: A003 NO [OVERQUOTA] APPEND Failed</t>
C:
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 a mailbox exceeds soft quota. Such responses have 2 response in the authenticated or the selected state, when a mailbox
forms. If it is followed by a tag, the tag refers to the command exceeds soft quota. For example, such OVERQUOTA response code might
that caused this (such as APPEND or COPY) and the OVERQUOTA response be sent as a result of an external event (e.g. LMTP delivery or
code applies to the target mailbox specified by such command. If the COPY/MOVE/APPEND in another IMAP connection) that causes the
OVERQUOTA response code is not followed by the tag, this means that currently selected mailbox to exceed soft quota. Note that such
an external event (e.g. LMTP delivery or APPEND/COPY in another IMAP OVERQUOTA response code might be ambiguous, because it might relate
connection) caused this event and the event applies to the currently to the target mailbox (as specified in COPY/MOVE/APPEND) or to the
selected mailbox. In particular, this means that such OVERQUOTA currently selected mailbox. (The WG chose not to address this
response codes MUST NOT be returned if there is no mailbox selected deficiency due to syntactic limitations of IMAP response codes and
or if a mailbox other than the currently selected one exceeds soft because such events are likely to be rare.) This form of the
quota. OVERQUOTA response codes MUST NOT be returned if there is no mailbox
selected and no command in progress that adds a message to a mailbox
(e.g. APPEND).
Example: Example 2: C: A003 APPEND saved-messages (\Seen) {326}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: * NO [OVERQUOTA] Soft quota has been exceeded
S: A003 OK [APPENDUID 38505 3955] APPEND completed
S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} Example 3: C: A003 COPY 2:4 MEETING
S: + Ready for literal data S: * NO [OVERQUOTA] Soft quota has been exceeded
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY completed
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: * NO [OVERQUOTA A003] Soft quota has been exceeded
S: A003 OK [APPENDUID 38505 3955] APPEND 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 mupltiple resource types, and MUST advertise all server MAY support mupltiple resource types, and MUST advertise all
resource types it supports. resource types it supports.
5.1. STORAGE 5.1. STORAGE
skipping to change at page 14, line 42 skipping to change at page 15, line 5
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" [SP tag] resp-text-code =/ "OVERQUOTA"
number64 = 1*DIGIT number64 = 1*DIGIT
;; Unsigned 63-bit integer. ;; Unsigned 63-bit integer.
;; (0 <= n <= 9,223,372,036,854,775,807) ;; (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. In
particular, no quota information should be disclosed to anonymous
users.
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
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 add the "QUOTASET"
capability to the IMAP4 capabilities registry, with this document as
the reference.
IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4
capabilities registry and add a pointer to this document and to the
IMAP quota resource type registry established above.
IANA is requested to reserve all other capabilities starting with
"QUOTA=" prefix for future IETF stream standard track, informational
or experimental extensions 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, 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
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
capabilities registry and add a pointer to this document and to the
IMAP quota resource type registry established above.
IANA is requested to reserve all other capabilities starting with
"QUOTA=" prefix for future IETF stream standard track or experimental
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.
Extra required IMAP commands/responses: DELETED-STORAGE STATUS Extra required IMAP commands/responses: DELETED-STORAGE STATUS
request data item and response data item request data item and response data item
Extra optional IMAP commands/responses: N/A Extra optional IMAP commands/responses: N/A
Reference: Section 5.1 of RFCXXXX Reference: Section 5.1 of RFCXXXX
skipping to change at page 17, line 13 skipping to change at page 17, line 23
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. [[CREF3: Recheck against the final governed by the quota root. [[CREF3: Recheck against the final
description of "ANNOTATION-STORAGE".]] description of "ANNOTATION-STORAGE".]]
Extra required IMAP commands/responses: N/A Extra required IMAP commands/responses: N/A
Extra optional IMAP commands/responses: N/A Extra optional IMAP commands/responses: N/A
Reference: Section 5.4 of RFCXXXX Reference: Section 5.4 of RFCXXXX
10. Open Issues 10. Contributors
'"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?
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.
12. 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.
13. 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 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") that
must be implemented. For extensibility quota usage and quota limits must be implemented. For extensibility quota usage and quota limits
are now 63 bit unsigned integers. are now 63 bit unsigned integers.
14. References 13. References
14.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.
[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 18, line 34 skipping to change at page 18, 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>.
14.2. Informative References 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. 25 change blocks. 
83 lines changed or deleted 85 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/