draft-ietf-extra-imap-objectid-06.txt   draft-ietf-extra-imap-objectid-07.txt 
EXTRA B. Gondwana, Ed. EXTRA B. Gondwana, Ed.
Internet-Draft FastMail Internet-Draft FastMail
Updates: 3501 (if approved) July 19, 2018 Updates: 3501 (if approved) July 31, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: January 20, 2019 Expires: February 1, 2019
IMAP Extension for object identifiers IMAP Extension for object identifiers
draft-ietf-extra-imap-objectid-06 draft-ietf-extra-imap-objectid-07
Abstract Abstract
This document updates RFC3501 (IMAP4rev1) with persistent identifiers This document updates RFC3501 (IMAP4rev1) with persistent identifiers
on mailboxes and messages to allow clients to more efficiently re-use on mailboxes and messages to allow clients to more efficiently re-use
cached data when resources have changed location on the server. cached data when resources have changed location on the server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 January 20, 2019. This Internet-Draft will expire on February 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 24 skipping to change at page 2, line 24
5. EMAILID object identifier and THREADID correlator . . . . . . 6 5. EMAILID object identifier and THREADID correlator . . . . . . 6
5.1. EMAILID identifier for identical messages . . . . . . . . 6 5.1. EMAILID identifier for identical messages . . . . . . . . 6
5.2. THREADID identifer for related messages . . . . . . . . . 6 5.2. THREADID identifer for related messages . . . . . . . . . 6
5.3. New Message Data Items in FETCH and UID FETCH Commands . 7 5.3. New Message Data Items in FETCH and UID FETCH Commands . 7
6. New Filters on SEARCH command . . . . . . . . . . . . . . . . 9 6. New Filters on SEARCH command . . . . . . . . . . . . . . . . 9
7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation considerations . . . . . . . . . . . . . . . . 10 8. Implementation considerations . . . . . . . . . . . . . . . . 10
8.1. Assigning object identifiers . . . . . . . . . . . . . . 10 8.1. Assigning object identifiers . . . . . . . . . . . . . . 10
8.2. Interaction with special cases . . . . . . . . . . . . . 11 8.2. Interaction with special cases . . . . . . . . . . . . . 11
8.3. Client usage . . . . . . . . . . . . . . . . . . . . . . 11 8.3. Client usage . . . . . . . . . . . . . . . . . . . . . . 11
9. Future considerations . . . . . . . . . . . . . . . . . . . . 11 9. Future considerations . . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. draft-ietf-extra-imap-objectid-06 . . . . . . . . . . . 12 12.1. draft-ietf-extra-imap-objectid-07 . . . . . . . . . . . 13
12.2. draft-ietf-extra-imap-objectid-05 . . . . . . . . . . . 13 12.2. draft-ietf-extra-imap-objectid-06 . . . . . . . . . . . 13
12.3. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 13 12.3. draft-ietf-extra-imap-objectid-05 . . . . . . . . . . . 13
12.4. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13 12.4. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 13
12.5. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 14 12.5. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 14
12.6. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 14 12.6. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 14
12.7. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14 12.7. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 14
12.8. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14 12.8. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 15
12.9. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 15 12.9. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 15
12.10. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 15 12.10. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 15
12.11. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Appendix 1: ideas for implementing object identifiers . 15 13.1. Appendix 1: ideas for implementing object identifiers . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . 16 14.1. Normative References . . . . . . . . . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . 17 14.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
IMAP stores are often used by many clients. Each client may cache IMAP stores are often used by many clients. Each client may cache
data from the server so that they don't need to re-download data from the server so that they don't need to re-download
information. [RFC3501] defines that a mailbox can be uniquely information. [RFC3501] defines that a mailbox can be uniquely
referenced by its name and UIDVALIDITY, and a message within that referenced by its name and UIDVALIDITY, and a message within that
mailbox can be uniquely referenced by its mailbox (name + mailbox can be uniquely referenced by its mailbox (name +
UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and UIDVALIDITY) and UID. The triple of mailbox name, UIDVALIDITY and
UID is guaranteed to be immutable. UID is guaranteed to be immutable.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
messages, which can be used by the server to indicate messages which messages, which can be used by the server to indicate messages which
it has identified to be related. A server that does not implement it has identified to be related. A server that does not implement
threading will return NIL to all requests for THREADID. threading will return NIL to all requests for THREADID.
2. Conventions Used In This Document 2. Conventions Used In This Document
In examples, "C:" indicates lines sent by a client that is connected In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client. to a server. "S:" indicates lines sent by the server to the client.
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] when they "OPTIONAL" in this document are to be interpreted as described in BCP
appear in ALL CAPS. These words may also appear in this document in 14 [RFC2119] [RFC8174] when, and only when, they appear in all
lower case as plain English words, absent their normative meanings. capitals, as shown here.
3. CAPABILITY Identification 3. CAPABILITY Identification
IMAP servers that support this extension MUST include "OBJECTID" in IMAP servers that support this extension MUST include "OBJECTID" in
the response list to the CAPABILITY command. the response list to the CAPABILITY command.
4. MAILBOXID object identifier 4. MAILBOXID object identifier
The MAILBOXID is a server-allocated unique identifer for each The MAILBOXID is a server-allocated unique identifer for each
mailbox. mailbox.
The server MUST return the same MAILBOXID for a mailbox with the same The server MUST return the same MAILBOXID for a mailbox with the same
name and UIDVALIDITY. name and UIDVALIDITY.
The server MUST NOT report the same MAILBOXID for two mailboxes at The server MUST NOT report the same MAILBOXID for two mailboxes at
the same time. the same time.
The server MUST NOT reuse the same MAILBOXID for a mailbox which does The server MUST NOT reuse the same MAILBOXID for a mailbox which does
not obey all the invarients that [RFC3501] defines for a mailbox not obey all the invariants that [RFC3501] defines for a mailbox
which does not change name or UIDVALIDITY. which does not change name or UIDVALIDITY.
The server MUST keep the same MAILBOXID for the source and The server MUST keep the same MAILBOXID for the source and
destination when renaming a mailbox in a way which keeps the same destination when renaming a mailbox in a way which keeps the same
messages (but see [RFC3501] for the special case regarding renaming messages (but see [RFC3501] for the special case regarding renaming
of INBOX, which is treated as creating a new mailbox and moving the of INBOX, which is treated as creating a new mailbox and moving the
messages) messages)
4.1. New response code for CREATE 4.1. New response code for CREATE
skipping to change at page 9, line 44 skipping to change at page 10, line 5
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) [RFC5234] notation. Elements not defined here can be Form (ABNF) [RFC5234] notation. Elements not defined here can be
found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and
IMAP ABNF extensions [RFC4466] specifications. IMAP ABNF extensions [RFC4466] specifications.
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper- or lowercase characters to define insensitive. The use of upper- or lowercase characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
capability =/ "OBJECTID" capability =/ "OBJECTID"
fetch-att =/ "EMAILID" / "THREADID" fetch-att =/ "EMAILID" / "THREADID"
fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged- fetch-emailid-resp = "EMAILID" SP "(" objectid ")"
ext production from [RFC4466] ; follows tagged-ext production from [@!RFC4466]
fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil ) ;
follows tagged-ext production from [RFC4466]
msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil )
; follows tagged-ext production from [@!RFC4466]
objectid = 1*255(ALPHA / DIGIT / "_" / "-") ; characters in object msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp
identifiers are case ; significant
resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ; incorporated objectid = 1*255(ALPHA / DIGIT / "_" / "-")
before the expansion rule of ; atom [SP 1*<any TEXT-CHAR except "]">] ; characters in object identifiers are case
; that appears in [RFC3501] ; significant
search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
; incorporated before the expansion rule of
; atom [SP 1*&lt;any TEXT-CHAR except "]"&gt;]
; that appears in [@!RFC3501]
status-att =/ "MAILBOXID" search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid
status-att-value =/ "MAILBOXID" SP "(" objectid ")" ; follows tagged- status-att =/ "MAILBOXID"
ext production from [RFC4466]
status-att-value =/ "MAILBOXID" SP "(" objectid ")"
; follows tagged-ext production from [@!RFC4466]
8. Implementation considerations 8. Implementation considerations
8.1. Assigning object identifiers 8.1. Assigning object identifiers
All objectid values are allocated by the server. All objectid values are allocated by the server.
In the interests of reducing the possibilities of encoding mistakes, In the interests of reducing the possibilities of encoding mistakes,
objectids are restricted to a safe subset of possible byte values, objectids are restricted to a safe subset of possible byte values,
and in order to allow clients to allocate storage, they are and in order to allow clients to allocate storage, they are
skipping to change at page 12, line 9 skipping to change at page 12, line 23
A future extension to [RFC5228] could allow fileinto by MAILBOXID A future extension to [RFC5228] could allow fileinto by MAILBOXID
rather than name. rather than name.
An extension to allow fetching message content directly via EMAILID An extension to allow fetching message content directly via EMAILID
and message listings by THREADID could be proposed. and message listings by THREADID could be proposed.
10. IANA Considerations 10. IANA Considerations
IANA is requested to add "OBJECTID" to the "IMAP Capabilities" IANA is requested to add "OBJECTID" to the "IMAP Capabilities"
registry located at <http://www.iana.org/assignments/imap- registry located at <http://www.iana.org/assignments/imap-
capabilities>. capabilities> with a Reference of [[THIS RFC]].
IANA is requested to add "MAILBOXID" to the "IMAP Response Codes" IANA is requested to add "MAILBOXID" to the "IMAP Response Codes"
registry located at <https://www.iana.org/assignments/imap-response- registry located at <https://www.iana.org/assignments/imap-response-
codes> with a Reference of [[THIS RFC]]. codes> with a Reference of [[THIS RFC]].
11. Security Considerations 11. Security Considerations
It is strongly advised that servers generate OBJECTIDs which are safe It is strongly advised that servers generate OBJECTIDs which are safe
to use as filesystem names, and unlikely to be auto-detected as to use as filesystem names, and unlikely to be auto-detected as
numbers. See implementation considerations. numbers. See implementation considerations.
If a digest is used for ID generation, it must have a collision If a digest is used for ID generation, it must have a collision
resistent property, so server implementations are advised to monitor resistent property, so server implementations are advised to monitor
current security research and choose secure digests. As the IDs are current security research and choose secure digests. As the IDs are
generated by the server, it will be possible to migrate to a new hash generated by the server, it will be possible to migrate to a new hash
by just creating new IDs with the new algorithm. This is by just using the new algorith when creating new IDs. This is
particularly true if a prefix is used on each ID, which can be particularly true if a prefix is used on each ID, which can be
changed when the algorithm changes. changed when the algorithm changes.
The use of a digest for ID generation may be used as proof that a The use of a digest for ID generation may be used as proof that a
particular sequence of bytes was seen by the server, however this is particular sequence of bytes was seen by the server, however this is
only a risk if IDs are leaked to clients who don't have permission to only a risk if IDs are leaked to clients who don't have permission to
fetch the data directly. Servers that are expected to handle highly fetch the data directly. Servers that are expected to handle highly
sensitive data should consider using a ID generation mechanism which sensitive data should consider using a ID generation mechanism which
doesn't derive from a digest. doesn't derive from a digest.
See also the security considerations in [RFC3501] section 11. See also the security considerations in [RFC3501] section 11.
12. Changes 12. Changes
To be removed by the editor before publication To be removed by the editor before publication
12.1. draft-ietf-extra-imap-objectid-06 12.1. draft-ietf-extra-imap-objectid-07
o updated boilerplate to RFC8174 (Benjamin Kaduk review)
o fixed spelling of invariants (Benjamin Kaduk review)
o block quoted ABNF for better text formatting (Benjamin Kaduk
review)
o clarified that servers can just switch to a new digest without
changing old IDs (Benjamin Kaduk review)
o changed use of folder to mailbox to avoid confusion (Warren Kumari
review)
o made both IANA requests say "reference of this RFC" (Warren Kumari
review)
12.2. draft-ietf-extra-imap-objectid-06
o fixed one more missing space in ABNF (ad review) o fixed one more missing space in ABNF (ad review)
o made one more MUST for mailbox being retained on rename (genart o made one more MUST for mailbox being retained on rename (genart
review) review)
o updated ABNF to also extend msg-att-static (validator review) o updated ABNF to also extend msg-att-static (validator review)
o lowercased NIL => nil in ABNF (validator review) o lowercased NIL => nil in ABNF (validator review)
12.2. draft-ietf-extra-imap-objectid-05 12.3. draft-ietf-extra-imap-objectid-05
o changed some SHOULD to lower case in advice sections (genart o changed some SHOULD to lower case in advice sections (genart
review) review)
o clarified that THREADID MUST NOT change o clarified that THREADID MUST NOT change
12.3. draft-ietf-extra-imap-objectid-04 12.4. draft-ietf-extra-imap-objectid-04
o described NIL THREADID in more detail (ad review) o described NIL THREADID in more detail (ad review)
o made RFC5256 a normative reference (ad review) o made RFC5256 a normative reference (ad review)
o fixed ABNF missing quote (ad review) o fixed ABNF missing quote (ad review)
o documented hash upgrade process (ad review) o documented hash upgrade process (ad review)
o referenced RFC3501 for INBOX rename (ad review) o referenced RFC3501 for INBOX rename (ad review)
o referenced RFC3501 security considerations (secdir review) o referenced RFC3501 security considerations (secdir review)
o turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability o turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability
(genart review) (genart review)
o remove suggested algorithms which are no longer legitimate (genart o remove suggested algorithms which are no longer legitimate (genart
skipping to change at page 13, line 39 skipping to change at page 14, line 23
o remove suggested algorithms which are no longer legitimate (genart o remove suggested algorithms which are no longer legitimate (genart
review) review)
o updated proxy advice to suggest rewriting ids (genart review) o updated proxy advice to suggest rewriting ids (genart review)
o fixed minor gramatical issues (genart review) o fixed minor gramatical issues (genart review)
o required that EMAILID and THREADID are not identical (own o required that EMAILID and THREADID are not identical (own
decision) decision)
12.4. draft-ietf-extra-imap-objectid-03 12.5. draft-ietf-extra-imap-objectid-03
o added RFC3501 to Abstract o added RFC3501 to Abstract
o updated [[THIS RFC]] to not fail idnits o updated [[THIS RFC]] to not fail idnits
o changed jmap-mail to be informative rather than normative o changed jmap-mail to be informative rather than normative
o shortened IDs to stop wrapping and outdents in IMAP examples o shortened IDs to stop wrapping and outdents in IMAP examples
12.5. draft-ietf-extra-imap-objectid-02 12.6. draft-ietf-extra-imap-objectid-02
o added "Client usage" section o added "Client usage" section
12.6. draft-ietf-extra-imap-objectid-01 12.7. draft-ietf-extra-imap-objectid-01
o added "updates" for RFC3501 o added "updates" for RFC3501
o fixed domains in thread example o fixed domains in thread example
o described threading in more detail o described threading in more detail
o added IANA request for Response Code o added IANA request for Response Code
o clarified RFC2119 references o clarified RFC2119 references
skipping to change at page 14, line 24 skipping to change at page 15, line 4
o described threading in more detail o described threading in more detail
o added IANA request for Response Code o added IANA request for Response Code
o clarified RFC2119 references o clarified RFC2119 references
o simplified some waffle in wording o simplified some waffle in wording
o added security consideration to choose good digest o added security consideration to choose good digest
o added MAILBOXID-UID suggestion for EMAILID generation o added MAILBOXID-UID suggestion for EMAILID generation
o updated ABNF normative reference to RFC5234 o updated ABNF normative reference to RFC5234
12.7. draft-ietf-extra-imap-objectid-00 12.8. draft-ietf-extra-imap-objectid-00
o renamed draft to be objectid rather than uniqueid o renamed draft to be objectid rather than uniqueid
o renamed UNIQUEID (capability) to OBJECTID o renamed UNIQUEID (capability) to OBJECTID
o restricted objectid to 64 safe characters o restricted objectid to 64 safe characters
o added security considerations and advice about choosing objectid o added security considerations and advice about choosing objectid
o wrapped all responses in () for RFC4466 compatibility o wrapped all responses in () for RFC4466 compatibility
o signifiant rewrite of all sections o signifiant rewrite of all sections
12.8. draft-ietf-extra-imap-uniqueid-00 12.9. draft-ietf-extra-imap-uniqueid-00
o renamed draft to be an EXTRA document o renamed draft to be an EXTRA document
o added example for LIST RETURN STATUS o added example for LIST RETURN STATUS
o started work on ABNF o started work on ABNF
o attempted to add response codes for EMAILID and THREADID o attempted to add response codes for EMAILID and THREADID
12.9. draft-gondwana-imap-uniqueid-01 12.10. draft-gondwana-imap-uniqueid-01
o renamed UNIQUEID (status item) to MAILBOXID o renamed UNIQUEID (status item) to MAILBOXID
o renamed MSGID to EMAILID o renamed MSGID to EMAILID
o renamed THRID to THREADID o renamed THRID to THREADID
o added TODO section o added TODO section
12.10. draft-gondwana-imap-uniqueid-00 12.11. draft-gondwana-imap-uniqueid-00
o initial upload with names UNIQUEID/MSGID/THRID o initial upload with names UNIQUEID/MSGID/THRID
13. Acknowledgments 13. Acknowledgments
The EXTRA working group at IETF. In particular feedback from Arnt The EXTRA working group at IETF. In particular feedback from Arnt
Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek. Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek.
The Gmail X-GM-THRID and X-GM-MSGID implementation as currently The Gmail X-GM-THRID and X-GM-MSGID implementation as currently
defined at <https://developers.google.com/gmail/imap/imap- defined at <https://developers.google.com/gmail/imap/imap-
skipping to change at page 16, line 4 skipping to change at page 16, line 34
o Server assigned sequence number (guaranteed not to be reused) o Server assigned sequence number (guaranteed not to be reused)
Ideas for implementing THREADID: Ideas for implementing THREADID:
o Derive from EMAILID of first seen message in the thread. o Derive from EMAILID of first seen message in the thread.
o [RFC4122] UUID o [RFC4122] UUID
o Server assigned sequence number (guaranteed not to be reused) o Server assigned sequence number (guaranteed not to be reused)
There is a need to index and look up reference/in-reply-to data at There is a need to index and look up reference/in-reply-to data at
message creation to efficiently find matching messages for threading. message creation to efficiently find matching messages for threading.
Threading may be either across folders, or within each folder only. Threading may be either across mailboxes, or within each mailbox
The server has significant leeway here. only. The server has significant leeway here.
14. References 14. References
14.1. Normative References 14.1. Normative References
[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>.
skipping to change at page 17, line 10 skipping to change at page 17, line 37
[RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for
Returning STATUS Information in Extended LIST", RFC 5819, Returning STATUS Information in Extended LIST", RFC 5819,
DOI 10.17487/RFC5819, March 2010, DOI 10.17487/RFC5819, March 2010,
<https://www.rfc-editor.org/info/rfc5819>. <https://www.rfc-editor.org/info/rfc5819>.
[RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message
Access Protocol (IMAP) - MOVE Extension", RFC 6851, Access Protocol (IMAP) - MOVE Extension", RFC 6851,
DOI 10.17487/RFC6851, January 2013, DOI 10.17487/RFC6851, January 2013,
<https://www.rfc-editor.org/info/rfc6851>. <https://www.rfc-editor.org/info/rfc6851>.
[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>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-jmap-mail] [I-D.ietf-jmap-mail]
Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-06 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-06
(work in progress), July 2018. (work in progress), July 2018.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
 End of changes. 36 change blocks. 
55 lines changed or deleted 80 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/