draft-ietf-extra-imap-objectid-00.txt   draft-ietf-extra-imap-objectid-01.txt 
EXTRA B. Gondwana, Ed. EXTRA B. Gondwana
Internet-Draft FastMail Internet-Draft FastMail
Intended status: Standards Track April 20, 2018 Intended status: Standards Track April 24, 2018
Expires: October 22, 2018 Expires: October 26, 2018
IMAP Extension for object identifiers IMAP Extension for object identifiers
draft-ietf-extra-imap-objectid-00 draft-ietf-extra-imap-objectid-01
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 32
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 22, 2018. This Internet-Draft will expire on October 26, 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 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3 3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3
4. MAILBOXID object identifier . . . . . . . . . . . . . . . . . 3 4. MAILBOXID object identifier . . . . . . . . . . . . . . . . . 3
4.1. New response code for CREATE . . . . . . . . . . . . . . 4 4.1. New response code for CREATE . . . . . . . . . . . . . . 4
4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4 4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4
4.3. New attribute for STATUS . . . . . . . . . . . . . . . . 4 4.3. New attribute for STATUS . . . . . . . . . . . . . . . . 5
5. EMAILID object identifier and THREADID correlator . . . . . . 5 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 . 6 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. Ideas for implementing object identifiers . . . . . . . . 11 9. Future considerations . . . . . . . . . . . . . . . . . . . . 11
9. Future considerations . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. draft-ietf-extra-imap-objectid-01 . . . . . . . . . . . 12
12.2. draft-ietf-extra-imap-objectid-00 . . . . . . . . . . . 12
12.3. draft-ietf-extra-imap-uniqueid-00 . . . . . . . . . . . 13
12.4. draft-gondwana-imap-uniqueid-01 . . . . . . . . . . . . 13
12.5. draft-gondwana-imap-uniqueid-00 . . . . . . . . . . . . 13
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Appendix 1: ideas for implementing object identifiers . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
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 4, line 12 skipping to change at page 4, line 19
The server MAY choose to create a MAILBOXID value in a way that does The server MAY choose to create a MAILBOXID value in a way that does
not survive RENAME (e.g. a digest of name + uidvalidity could be not survive RENAME (e.g. a digest of name + uidvalidity could be
used), however the client then loses the major benefit of having an used), however the client then loses the major benefit of having an
identifier. identifier.
4.1. New response code for CREATE 4.1. New response code for CREATE
This document extends the CREATE command to have the response code This document extends the CREATE command to have the response code
MAILBOXID on successful mailbox creation. MAILBOXID on successful mailbox creation.
A server advertising the OBJECTID capability MUST include the
MAILBOXID response code in the tagged OK response to all successful
CREATE commands.
Syntax: "MAILBOXID" SP "(" <objectid> ")" Syntax: "MAILBOXID" SP "(" <objectid> ")"
Response code in tagged OK for successful CREATE command. Response code in tagged OK for successful CREATE command.
Example: Example:
C: 3 create foo C: 3 create foo
S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)] Completed S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)] Completed
C: 4 create bar C: 4 create bar
S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)] Completed S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)] Completed
C: 5 create foo C: 5 create foo
S: 5 NO Mailbox already exists S: 5 NO Mailbox already exists
4.2. New OK Untagged Response for SELECT and EXAMINE 4.2. New OK Untagged Response for SELECT and EXAMINE
This document adds a new untagged response code to any successful This document adds a new untagged response code to the SELECT and
SELECT or EXAMINE command. A server advertising OBJECTID capability
MUST return this untagged response to all successful SELECT and
EXAMINE commands. EXAMINE commands.
A server advertising the OBJECTID capability MUST return an untagged
OK response with the MAILBOXID response code on all successful SELECT
and EXAMINE commands.
Syntax: "OK" SP "[" "MAILBOXID" SP "(" <objectid> ")" "]" text Syntax: "OK" SP "[" "MAILBOXID" SP "(" <objectid> ")" "]" text
Untagged OK response to SELECT or EXAMINE. Untagged OK response to SELECT or EXAMINE.
Example: Example:
C: 27 select "foo" C: 27 select "foo"
[...] [...]
S: * OK [UIDVALIDITY 1524195797] Ok S: * OK [UIDVALIDITY 1524195797] Ok
S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)] Ok S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)] Ok
[...] [...]
S: 27 OK [READ-WRITE] Completed S: 27 OK [READ-WRITE] Completed
4.3. New attribute for STATUS 4.3. New attribute for STATUS
This document adds the MAILBOXID attribute to the STATUS command This document adds the MAILBOXID attribute to the STATUS command
using the extended syntax defined in [RFC4466]. using the extended syntax defined in [RFC4466].
A server that advertises the OBJECTID capability MUST support the
MAILBOXID status attribute.
Syntax: "MAILBOXID" Syntax: "MAILBOXID"
The attribute in the STATUS command. The attribute in the STATUS command.
Syntax: "MAILBOXID" SP "(" <objectid> ")" Syntax: "MAILBOXID" SP "(" <objectid> ")"
The response item in the STATUS response contains the objectid The response item in the STATUS response contains the objectid
assigned by the server for this mailbox. assigned by the server for this mailbox.
Example: Example:
C: 6 status foo (mailboxid) C: 6 status foo (mailboxid)
skipping to change at page 5, line 29 skipping to change at page 5, line 47
C: 8 rename foo renamed C: 8 rename foo renamed
S: * OK rename foo renamed S: * OK rename foo renamed
S: 8 OK Completed S: 8 OK Completed
C: 9 status renamed (mailboxid) C: 9 status renamed (mailboxid)
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)) S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625))
S: 9 OK Completed S: 9 OK Completed
C: 10 status bar (mailboxid) C: 10 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)) S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3))
S: 10 OK Completed S: 10 OK Completed
When the LIST-STATUS IMAP capability [RFC5819] is also available, the When the LIST-STATUS IMAP capability defined in [RFC5819] is also
STATUS command can be combined with the LIST command to further available, the STATUS command can be combined with the LIST command.
improve efficiency. This way, the MAILBOXIDs of many mailboxes can
be queried with just one LIST command.
Example: Example:
C: 11 list "" "*" return (status (mailboxid)) C: 11 list "" "*" return (status (mailboxid))
S: * LIST (\HasNoChildren) "." INBOX S: * LIST (\HasNoChildren) "." INBOX
S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf)) S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))
S: * LIST (\HasNoChildren) "." bar S: * LIST (\HasNoChildren) "." bar
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3)) S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d47cf8b48ee3))
S: * LIST (\HasNoChildren) "." renamed S: * LIST (\HasNoChildren) "." renamed
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625)) S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-716686338625))
S: 11 OK Completed (0.001 secs 3 calls) S: 11 OK Completed (0.001 secs 3 calls)
5. EMAILID object identifier and THREADID correlator 5. EMAILID object identifier and THREADID correlator
This document adds two additional data items to individual email This document defines the data items EMAILID and THREADID on
messages within a mailbox, EMAILID and THREADID. messages.
5.1. EMAILID identifier for identical messages 5.1. EMAILID identifier for identical messages
The EMAILID data item is an objectid which uniquely identifies the The EMAILID data item is an objectid which uniquely identifies the
content of a single message. Anything which must remain immutable on content of a single message. Anything which must remain immutable on
a {name, uidvalidity, uid} triple must also be the same between a {name, uidvalidity, uid} triple must also be the same between
messages with the same EMAILID. messages with the same EMAILID.
The server SHOULD return the same EMAILID for the same UID triple. The server SHOULD return the same EMAILID for the same UID triple.
As with MAILBOXID above, this is almost a MUST, but allows for the As with MAILBOXID above, this is almost a MUST, but allows for the
possibility of loss of OBJECTID data in disaster recovery without possibility of loss of OBJECTID data in disaster recovery without
having to change UIDVALIDITY. having to change UIDVALIDITY.
The server SHOULD return the same EMAILID for the exact same message The server SHOULD return the same EMAILID for the exact same message
content in different folders after a COPY or [RFC6851] MOVE command. content in different folders after a COPY or [RFC6851] MOVE command.
The server MAY us content detection to assign the same EMAILID upon The server MAY assign the same EMAILID as an existing message upon
APPEND of an identical message. APPEND if it detects that the new message has exactly identical
content to that existing message.
5.2. THREADID identifer for related messages 5.2. THREADID identifer for related messages
The THREADID data item is an objectid which uniquely identifies as The THREADID data item is an objectid which uniquely identifies a set
set of messages which the server believes are related in some way. of messages which the server believes should be grouped together when
presented.
THREADID calculation is generally based on some combination of THREADID calculation is generally based on some combination of
References, In-Reply-To and Subject, but the exact logic is left up References, In-Reply-To and Subject, but the exact logic is left up
to the server implementation. to the server implementation. [RFC5256] describes some algorithms
that MAY be used, however this specfication does not mandate any
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.
THREADID is optional, if the server is unable to calculate THREADID is optional, if the server is unable to calculate
relationships between messages, it MUST return NIL to in all FETCH relationships between messages, it MUST return NIL to in all FETCH
responses for the THREADID data item, and it MUST NOT match any responses for the THREADID data item, and a SEARCH for THREADID MUST
messages for any value of THREADID. NOT match any messages.
The server MAY use the same value for both EMAILID and THREADID, for The server MAY use the same objectid value for both EMAILID and
example the THREADID could be the EMAILID of the first message seen THREADID, for example the THREADID could be the EMAILID of the first
in each thread. message that the server has seen in each thread.
5.3. New Message Data Items in FETCH and UID FETCH Commands 5.3. New Message Data Items in FETCH and UID FETCH Commands
This document specifies two new FETCH items for messages: This document defines two FETCH items:
Syntax: EMAILID Syntax: EMAILID
The EMAILID message data item causes the server to return EMAILID The EMAILID message data item causes the server to return EMAILID
FETCH response data items. FETCH response data items.
Syntax: THREADID Syntax: THREADID
The THREADID message data item causes the server to return THREADID The THREADID message data item causes the server to return THREADID
FETCH response data items. FETCH response data items.
And the following responses: And the following responses:
skipping to change at page 8, line 8 skipping to change at page 8, line 8
Syntax: THREADID NIL Syntax: THREADID NIL
The NIL value to the THREADID response data item is returned when The NIL value to the THREADID response data item is returned when
the server mailbox does not support THREADID calculation. the server mailbox does not support THREADID calculation.
Example: Example:
C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733} C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733}
[...] [...]
Subject: Message A Subject: Message A
Message-ID: <fake.1521475657.54797@hotmail.com> Message-ID: <fake.1521475657.54797@example.com>
[...] [...]
S: 5 OK [APPENDUID 1521475658 1] Completed S: 5 OK [APPENDUID 1521475658 1] Completed
C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793} C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793}
[...] [...]
Subject: Re: Message A Subject: Re: Message A
Message-ID: <fake.1521475657.21213@gmail.com> Message-ID: <fake.1521475657.21213@example.org>
References: <fake.1521475657.54797@hotmail.com> References: <fake.1521475657.54797@example.com>
[...] [...]
S: 11 OK [APPENDUID 1521475658 2] Completed S: 11 OK [APPENDUID 1521475658 2] Completed
C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736} C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736}
[...] [...]
Subject: Message C Subject: Message C
Message-ID: <fake.1521475657.60280@hotmail.com> Message-ID: <fake.1521475657.60280@example.com>
[...] [...]
S: 17 OK [APPENDUID 1521475658 3] Completed S: 17 OK [APPENDUID 1521475658 3] Completed
C: 22 fetch 1:* (emailid threadid) C: 22 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (Md8976d99ac3275bb4e) THREADID (T4964b478a75b7ea9)) S: * 1 FETCH (EMAILID (M8976d99ac3275bb4e) THREADID (T4964b478a75b7ea9))
S: * 2 FETCH (EMAILID (Mdd3c288836c4c7a762) THREADID (T4964b478a75b7ea9)) S: * 2 FETCH (EMAILID (Md3c288836c4c7a762) THREADID (T4964b478a75b7ea9))
S: * 3 FETCH (EMAILID (Mf2e25fdc09b49ea703) THREADID (T6311863d02dd95b5)) S: * 3 FETCH (EMAILID (M2e25fdc09b49ea703) THREADID (T6311863d02dd95b5))
S: 22 OK Completed (0.000 sec) S: 22 OK Completed (0.000 sec)
C: 23 move 2 foo C: 23 move 2 foo
S: * OK [COPYUID 1521475659 2 1] Completed S: * OK [COPYUID 1521475659 2 1] Completed
S: * 2 EXPUNGE S: * 2 EXPUNGE
S: 23 OK Completed S: 23 OK Completed
C: 24 fetch 1:* (emailid threadid) C: 24 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (Md8976d99ac3275bb4e) THREADID (T4964b478a75b7ea9)) S: * 1 FETCH (EMAILID (M8976d99ac3275bb4e) THREADID (T4964b478a75b7ea9))
S: * 2 FETCH (EMAILID (Mf2e25fdc09b49ea703) THREADID (T6311863d02dd95b5)) S: * 2 FETCH (EMAILID (M2e25fdc09b49ea703) THREADID (T6311863d02dd95b5))
S: 24 OK Completed (0.000 sec) S: 24 OK Completed (0.000 sec)
C: 25 select "foo" C: 25 select "foo"
C: 25 select "foo" C: 25 select "foo"
[...] [...]
S: 25 OK [READ-WRITE] Completed S: 25 OK [READ-WRITE] Completed
C: 26 fetch 1:* (emailid threadid) C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (Mdd3c288836c4c7a762) THREADID (T4964b478a75b7ea9)) S: * 1 FETCH (EMAILID (Md3c288836c4c7a762) THREADID (T4964b478a75b7ea9))
S: 26 OK Completed (0.000 sec) S: 26 OK Completed (0.000 sec)
Example: (no THREADID support) Example: (no THREADID support)
C: 26 fetch 1:* (emailid threadid) C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M00000001) THREADID NIL) S: * 1 FETCH (EMAILID (M00000001) THREADID NIL)
S: * 2 FETCH (EMAILID (M00000002) THREADID NIL) S: * 2 FETCH (EMAILID (M00000002) THREADID NIL)
S: 26 OK Completed (0.000 sec) S: 26 OK Completed (0.000 sec)
6. New Filters on SEARCH command 6. New Filters on SEARCH command
This extension defines the EMAILID and THREADID filters for the This document defines filters EMAILID and THREADID on the SEARCH
SEARCH command. command.
EMAILID <objectid> EMAILID <objectid>
Messages whose EMAILID is exactly the specified objectid. Messages whose EMAILID is exactly the specified objectid.
THREADID <objectid> THREADID <objectid>
Messages whose THREADID is exactly the specified objectid. Messages whose THREADID is exactly the specified objectid.
Example: (as if run before the MOVE above when the mailbox had 3 Example: (as if run before the MOVE above when the mailbox had 3
messages) messages)
C: 27 search emailid Md8976d99ac3275bb4e918af4 C: 27 search emailid M8976d99ac3275bb4e
S: * SEARCH 1 S: * SEARCH 1
S: 27 OK Completed (1 msgs in 0.000 secs) S: 27 OK Completed (1 msgs in 0.000 secs)
C: 28 search threadid T4964b478a75b7ea9 C: 28 search threadid T4964b478a75b7ea9
S: * SEARCH 1 2 S: * SEARCH 1 2
S: 28 OK Completed (2 msgs in 0.000 secs) S: 28 OK Completed (2 msgs in 0.000 secs)
7. Formal syntax 7. Formal syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) [RFC4234] 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 [RFC4234], 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]
fetch-threadid-resp = "THREADID" SP "(" objectid ")" ;; follows
tagged-ext production from [RFC4466]
objectid = 1*255(ALPHA / DIGIT / "_" / "-") ;; characters in object ; follows tagged-ext production from [@!RFC4466]
identifiers are case ;; significant
resp-text-code =/ "MAILBOXID" SP "(" objectid ")" ;; incorporated fetch-threadid-resp = "THREADID" SP "(" objectid ")" /
before the expansion rule of ;; atom [SP 1*<any TEXT-CHAR except
"]">] ;; that appears in [RFC3501] "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 ")"
; incorporated before the expansion rule of
; atom [SP 1*&lt;any TEXT-CHAR except "]"&gt;]
; 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 ")" ;; follows status-att-value =/ "MAILBOXID" SP "(" objectid ")"
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 10, line 44 skipping to change at page 11, line 4
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 they it is only required to be unique within a single unique, but it is only required to be unique within messages offered
server. to a single client login to a single server hostname. For example, a
proxy which aggregates multiple independent servers MUST NOT
8.3. Ideas for implementing object identifiers advertise the OBJECTID capability unless it can guarantee that the
backends will not use the same identifiers for different objects.
This section contains non-normative suggestions.
Ideas for implementing MAILBOXID:
o Digest of (MailboxName/UIDVALIDITY) - not kept when renaming, but
is guaranteed unique and doesn't require storage.
o [RFC4122] UUID
o Server assigned sequence number (guaranteed not to be reused)
Ideas for implementing EMAILID:
o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying
messages, but is guaranteed unique and doesn't require storage.
o Digest of message content (RFC822 bytes) - expensive unless cached
o [RFC4122] UUID
o Server assigned sequence number (guaranteed not to be reused)
Ideas for implementing THREADID:
o Derive from EMAILID of first seen message in the thread.
o [RFC4122] UUID
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
message creation to efficiently find matching messages for threading.
Threading may be either across folders, or within each folder only.
The server has significant leeway here.
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.
10. IANA Considerations 10. IANA Considerations
The 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>.
IANA is requested to add "MAILBOXID" to the "IMAP Response Codes"
registry located at <https://www.iana.org/assignments/imap-response-
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
resistent property, so server implementations are advised to monitor
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. 01 12.1. draft-ietf-extra-imap-objectid-01
o renamed UNIQUEID (capability) to OBJECTID (and renamed the draft o added "updates" for RFC3501
as well)
o renamed UNIQUEID (status item) to MAILBOXID o fixed domains in thread example
o renamed MSGID to EMAILID o described threading in more detail
o renamed THRID to THREADID o added IANA request for Response Code
o clarified RFC2119 references
o simplified some waffle in wording
o added security consideration to choose good digest
o added MAILBOXID-UID suggestion for EMAILID generation
o updated ABNF normative reference to RFC5234
12.2. draft-ietf-extra-imap-objectid-00
o renamed draft to be objectid rather than uniqueid
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
o renamed draft to be an EXTRA document
o added example for LIST RETURN STATUS
o started work on ABNF
o attempted to add response codes for EMAILID and THREADID
12.4. draft-gondwana-imap-uniqueid-01
o renamed UNIQUEID (status item) to MAILBOXID
o renamed MSGID to EMAILID
o renamed THRID to THREADID
o added TODO section
12.5. draft-gondwana-imap-uniqueid-00
o initial upload with names UNIQUEID/MSGID/THRID
13. Acknowledgments 13. Acknowledgments
The EXTRA working group at IETF. The EXTRA working group at IETF. In particular feedback from Arnt
Gulbrandsen, Brandon Long, Chris Newman and Josef Sipek.
The gmail team's X-GM-THRID and X-GM-MSGID implementation. The Gmail X-GM-THRID and X-GM-MSGID implementation as currently
defined at <https://developers.google.com/gmail/imap/imap-
extensions>.
Dovecot X-GUID implementation.
13.1. Appendix 1: ideas for implementing object identifiers
Ideas for implementing MAILBOXID:
o Digest of (MailboxName/UIDVALIDITY) - not kept when renaming, but
is guaranteed unique and doesn't require storage.
o [RFC4122] UUID
o Server assigned sequence number (guaranteed not to be reused)
Ideas for implementing EMAILID:
o Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when copying
messages, but is guaranteed unique and doesn't require storage.
o Concatenation of MAILBOXID-UID - for servers which store MAILBOXID
but not EMAILID.
o Digest of message content (RFC822 bytes) - expensive unless cached
o [RFC4122] UUID
o Server assigned sequence number (guaranteed not to be reused)
Ideas for implementing THREADID:
o Derive from EMAILID of first seen message in the thread.
o [RFC4122] UUID
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
message creation to efficiently find matching messages for threading.
Threading may be either across folders, or within each folder only.
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-04
(work in progress), March 2018. (work in progress), March 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>.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234,
October 2005, <https://www.rfc-editor.org/info/rfc4234>.
[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
December 2005, <https://www.rfc-editor.org/info/rfc4315>. December 2005, <https://www.rfc-editor.org/info/rfc4315>.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
<https://www.rfc-editor.org/info/rfc4466>. <https://www.rfc-editor.org/info/rfc4466>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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>.
14.2. Informative References 14.2. Informative References
[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>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>.
Author's Address Author's Address
Bron Gondwana (editor) Bron Gondwana
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. 54 change blocks. 
122 lines changed or deleted 210 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/