< draft-ietf-extra-imap-objectid-01.txt   draft-ietf-extra-imap-objectid-02.txt >
EXTRA B. Gondwana EXTRA B. Gondwana, Ed.
Internet-Draft FastMail Internet-Draft FastMail
Intended status: Standards Track April 24, 2018 Updates: 3501 (if approved) May 26, 2018
Expires: October 26, 2018 Intended status: Standards Track
Expires: November 27, 2018
IMAP Extension for object identifiers IMAP Extension for object identifiers
draft-ietf-extra-imap-objectid-01 draft-ietf-extra-imap-objectid-02
Abstract Abstract
This document adds new properties to IMAP mailboxes and messages to This document adds new properties to IMAP mailboxes and messages to
allow clients to more efficiently re-use cached data for resources allow clients to more efficiently re-use cached data for resources
which have changed location on the server. which 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 32 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 October 26, 2018. This Internet-Draft will expire on November 27, 2018.
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 23 skipping to change at page 2, line 23
4.3. New attribute for STATUS . . . . . . . . . . . . . . . . 5 4.3. New attribute for STATUS . . . . . . . . . . . . . . . . 5
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
9. Future considerations . . . . . . . . . . . . . . . . . . . . 11 9. Future considerations . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 12 12.1. draft-ietf-extra-imap-objectid-02 . . . . . . . . . . . 12
12.2. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 12 12.2. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 12
12.3. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 13 12.3. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 13
12.4. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 13 12.4. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 13
12.5. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 13 12.5. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 13
12.6. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 13
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Appendix 1: ideas for implementing object identifiers . 13 13.1. Appendix 1: ideas for implementing object identifiers . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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 9, line 48 skipping to change at page 9, line 48
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 ")" fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged-
ext production from [RFC4466]
; follows tagged-ext production from [@!RFC4466] fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID NIL
; follows tagged-ext production from [RFC4466]
fetch-threadid-resp = "THREADID" SP "(" objectid ")" /
"THREADID NIL
; follows tagged-ext production from [@!RFC4466]
objectid = 1*255(ALPHA / DIGIT / "_" / "-")
; characters in object identifiers are case
; significant
resp-text-code =/ "MAILBOXID" SP "(" objectid ")" objectid = 1*255(ALPHA / DIGIT / "_" / "-") ; characters in object
identifiers are case ; significant
; incorporated before the expansion rule of resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ; incorporated
; atom [SP 1*&lt;any TEXT-CHAR except "]"&gt;] before the expansion rule of ; atom [SP 1*<any TEXT-CHAR except "]">]
; that appears in [@!RFC3501] ; that appears in [RFC3501]
search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid
status-att =/ "MAILBOXID" status-att =/ "MAILBOXID"
status-att-value =/ "MAILBOXID" SP "(" objectid ")" status-att-value =/ "MAILBOXID" SP "(" objectid ")" ; follows tagged-
ext production from [RFC4466]
; 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 11, line 4 skipping to change at page 10, line 44
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
o ids which differ only by ASCII case (A vs a) o ids which differ only by ASCII case (A vs a)
o the specific sequence of 3 characters NIL o the specific sequence of 3 characters NIL
A good solution to these issues is to prefix every ID with a single A good solution to these issues is to prefix every ID with a single
alphabetical character. alphabetical character.
8.2. Interaction with special cases 8.2. Interaction with special cases
The case of RENAME INBOX may need special handling for unique ids. The case of RENAME INBOX may need special handling for unique ids.
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 the advertise the OBJECTID capability unless it can guarantee that the
backends will not use the same identifiers for different objects. backends will not use the same identifiers for different objects.
8.3. Client usage
Servers that implement both RFC 6154 and this specification SHOULD
optimize their execution of command like UID SEARCH OR EMAILID 1234
EMAILID 4321.
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
other client has moved them out of the mailbox where they were
previously seen.
Clients that cache data offline SHOULD fetch the EMAILID of all new
messages to avoid re-downloading already cached message details.
Clients SHOULD fetch the MAILBOXID for any new mailboxes before
discarding cache data for any mailbox which is no longer present on
the server, so that they can detect renames and avoid re-downloading
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
mailbox by MAILBOXID rather than name. mailbox by MAILBOXID 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.
skipping to change at page 12, line 16 skipping to change at page 12, line 32
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. current security research and choose secure digests.
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. particular sequence of bytes was seen by the server.
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-01 12.1. draft-ietf-extra-imap-objectid-02
o added "Client usage" section
12.2. 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 12, line 33 skipping to change at page 13, line 4
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.2. draft-ietf-extra-imap-objectid-00 12.3. 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.3. draft-ietf-extra-imap-uniqueid-00 12.4. 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.4. draft-gondwana-imap-uniqueid-01 12.5. 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.5. draft-gondwana-imap-uniqueid-00 12.6. 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 14, line 35 skipping to change at page 14, line 50
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 folders, or within each folder only.
The server has significant leeway here. The server has significant leeway here.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-jmap-mail] [I-D.ietf-jmap-mail]
Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-04 Jenkins, N., "JMAP for Mail", draft-ietf-jmap-mail-05
(work in progress), March 2018. (work in progress), May 2018.
[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>.
skipping to change at page 15, line 38 skipping to change at page 16, line 7
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>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008, DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>. <https://www.rfc-editor.org/info/rfc5256>.
Author's Address Author's Address
Bron Gondwana Bron Gondwana (editor)
FastMail FastMail
Level 2, 114 William St Level 2, 114 William St
Melbourne VIC 3000 Melbourne VIC 3000
Australia Australia
Email: brong@fastmailteam.com Email: brong@fastmailteam.com
URI: https://www.fastmail.com URI: https://www.fastmail.com
 End of changes. 24 change blocks. 
44 lines changed or deleted 60 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/