draft-ietf-extra-imap-objectid-04.txt   draft-ietf-extra-imap-objectid-05.txt 
EXTRA B. Gondwana, Ed. EXTRA B. Gondwana, Ed.
Internet-Draft FastMail Internet-Draft FastMail
Updates: 3501 (if approved) July 17, 2018 Updates: 3501 (if approved) July 17, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: January 18, 2019 Expires: January 18, 2019
IMAP Extension for object identifiers IMAP Extension for object identifiers
draft-ietf-extra-imap-objectid-04 draft-ietf-extra-imap-objectid-05
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 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 12 12.1. draft-ietf-extra-imap-objectid-05 . . . . . . . . . . . 12
12.2. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13 12.2. draft-ietf-extra-imap-objectid-04 . . . . . . . . . . . 13
12.3. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 13 12.3. draft-ietf-extra-imap-objectid-03 . . . . . . . . . . . 13
12.4. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 13 12.4. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 13
12.5. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14 12.5. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 13
12.6. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14 12.6. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 14
12.7. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 14 12.7. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 14
12.8. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 14 12.8. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 14
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 12.9. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Appendix 1: ideas for implementing object identifiers . 15 13.1. Appendix 1: ideas for implementing object identifiers . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . 16 14.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
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 7, line 8 skipping to change at page 7, line 8
to the server implementation. [RFC5256] describes some algorithms to the server implementation. [RFC5256] describes some algorithms
that could be used, however this specfication does not mandate any that could be used, however this specfication does not mandate any
particular strategy. particular strategy.
The server MUST return the same THREADID for all messages with the The server MUST return the same THREADID for all messages with the
same EMAILID. same EMAILID.
The server SHOULD return the same THREADID for related messages even The server SHOULD return the same THREADID for related messages even
if they are in different mailboxes. if they are in different mailboxes.
The server MUST NOT change the THREADID of a message once reported.
THREADID is optional, if the server doesn't support THREADID or is THREADID is optional, if the server doesn't support THREADID or is
unable to calculate relationships between messages, it MUST return unable to calculate relationships between messages, it MUST return
NIL to all FETCH responses for the THREADID data item, and a SEARCH NIL to all FETCH responses for the THREADID data item, and a SEARCH
for THREADID MUST NOT match any messages. for THREADID MUST NOT match any messages.
The server MUST NOT use the same objectid value for both EMAILIDs and The server MUST NOT use the same objectid value for both EMAILIDs and
THREADIDs. If they are stored with the same value internally, the THREADIDs. If they are stored with the same value internally, the
server can generate prefixed values (as shown in the examples below server can generate prefixed values (as shown in the examples below
with M and T prefixes) to avoid clashes. with M and T prefixes) to avoid clashes.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
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
restricted in length. restricted in length.
An objectid is a string of 1 to 255 characters from the following set An objectid is a string of 1 to 255 characters from the following set
of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. These characters are safe of 64 codepoints. a-z, A-Z, 0-9, '_', '-'. These characters are safe
to use in almost any context (e.g. filesystems, URIs, IMAP atoms). to use in almost any context (e.g. filesystems, URIs, IMAP atoms).
For maximum safety, servers SHOULD also follow defensive allocation For maximum safety, servers should also follow defensive allocation
strategies to avoid creating risks where glob completion or data type strategies to avoid creating risks where glob completion or data type
detection may be present (e.g. on filesystems or in spreadsheets). detection may be present (e.g. on filesystems or in spreadsheets).
In particular it is wise to avoid: In particular it is wise to avoid:
o ids starting with - o ids starting with -
o ids starting with digits o ids starting with digits
o ids which contain only digits o ids which contain only digits
skipping to change at page 11, line 22 skipping to change at page 11, line 22
It is advisable (though not required) to have MAILBOXID be globally It is advisable (though not required) to have MAILBOXID be globally
unique, but it is only required to be unique within messages offered unique, but it is only required to be unique within messages offered
to a single client login to a single server hostname. For example, a to a single client login to a single server hostname. For example, a
proxy which aggregates multiple independent servers MUST NOT proxy which aggregates multiple independent servers MUST NOT
advertise the OBJECTID capability unless it can guarantee that advertise the OBJECTID capability unless it can guarantee that
different objects will never use the same identifiers, even if different objects will never use the same identifiers, even if
backend object collide. backend object collide.
8.3. Client usage 8.3. Client usage
Servers that implement both RFC 6154 and this specification SHOULD Servers that implement both RFC 6154 and this specification should
optimize their execution of command like UID SEARCH OR EMAILID 1234 optimize their execution of command like UID SEARCH OR EMAILID 1234
EMAILID 4321. EMAILID 4321.
Clients can assume that searching the all-mail mailbox using OR/ Clients can assume that searching the all-mail mailbox using OR/
EMAILID or OR/THREADID is a fast way to find messages again if some EMAILID or OR/THREADID is a fast way to find messages again if some
other client has moved them out of the mailbox where they were other client has moved them out of the mailbox where they were
previously seen. previously seen.
Clients that cache data offline SHOULD fetch the EMAILID of all new Clients that cache data offline should fetch the EMAILID of all new
messages to avoid re-downloading already cached message details. messages to avoid re-downloading already cached message details.
Clients SHOULD fetch the MAILBOXID for any new mailboxes before Clients should fetch the MAILBOXID for any new mailboxes before
discarding cache data for any mailbox which is no longer present on discarding cache data for any mailbox which is no longer present on
the server, so that they can detect renames and avoid re-downloading the server, so that they can detect renames and avoid re-downloading
data. data.
9. Future considerations 9. Future considerations
This extension is intentionally defined to be compatible with the This extension is intentionally defined to be compatible with the
data model in [I-D.ietf-jmap-mail]. data model in [I-D.ietf-jmap-mail].
A future extension could be proposed to give a way to SELECT a A future extension could be proposed to give a way to SELECT a
skipping to change at page 12, line 42 skipping to change at page 12, line 42
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-04 12.1. draft-ietf-extra-imap-objectid-05
o changed some SHOULD to lower case in advice sections (genart
review)
o clarified that THREADID MUST NOT change
12.2. 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)
skipping to change at page 13, line 19 skipping to change at page 13, line 32
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.2. draft-ietf-extra-imap-objectid-03 12.3. 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.3. draft-ietf-extra-imap-objectid-02 12.4. draft-ietf-extra-imap-objectid-02
o added "Client usage" section o added "Client usage" section
12.4. draft-ietf-extra-imap-objectid-01 12.5. 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
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
skipping to change at page 14, line 5 skipping to change at page 14, line 16
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.5. draft-ietf-extra-imap-objectid-00 12.6. 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.6. draft-ietf-extra-imap-uniqueid-00 12.7. 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.7. draft-gondwana-imap-uniqueid-01 12.8. 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.8. draft-gondwana-imap-uniqueid-00 12.9. 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-
 End of changes. 17 change blocks. 
27 lines changed or deleted 36 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/