7Internet Engineering Task Force (IETF) B. Gondwana, Ed.
8Request for Comments: 8474 FastMail
9Updates: 3501 September 2018
10Category: Standards Track
14 IMAP Extension for Object Identifiers
18 This document updates RFC 3501 (IMAP4rev1) with persistent
19 identifiers on mailboxes and messages to allow clients to more
20 efficiently reuse cached data when resources have changed location on
25 This is an Internet Standards Track document.
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 7841.
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 https://www.rfc-editor.org/info/rfc8474.
39 Copyright (c) 2018 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
58Gondwana Standards Track [Page 1]
60RFC 8474 IMAP ObjectID September 2018
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
67 3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3
68 4. MAILBOXID Object Identifier . . . . . . . . . . . . . . . . . 3
69 4.1. New Response Code for CREATE . . . . . . . . . . . . . . 4
70 4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4
71 4.3. New Attribute for STATUS . . . . . . . . . . . . . . . . 5
72 5. EMAILID Object Identifier and THREADID Correlator . . . . . . 6
73 5.1. EMAILID Identifier for Identical Messages . . . . . . . . 6
74 5.2. THREADID Identifier for Related Messages . . . . . . . . 6
75 5.3. New Message Data Items in FETCH and UID FETCH Commands . 7
76 6. New Filters on SEARCH Command . . . . . . . . . . . . . . . . 9
77 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
78 8. Implementation Considerations . . . . . . . . . . . . . . . . 10
79 8.1. Assigning Object Identifiers . . . . . . . . . . . . . . 10
80 8.2. Interaction with Special Cases . . . . . . . . . . . . . 11
81 8.3. Client Usage . . . . . . . . . . . . . . . . . . . . . . 11
82 8.4. Advice to Client Implementers . . . . . . . . . . . . . . 12
83 9. Future Considerations . . . . . . . . . . . . . . . . . . . . 12
84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
87 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
88 12.2. Informative References . . . . . . . . . . . . . . . . . 14
89 Appendix A. Ideas for Implementing Object Identifiers . . . . . 15
90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
95 IMAP stores are often used by many clients. Each client may cache
96 data from the server so that it doesn't need to redownload
97 information. [RFC3501] states that a mailbox can be uniquely
98 referenced by its name and UIDVALIDITY, and a message within that
99 mailbox can be uniquely referenced by its mailbox (name +
100 UIDVALIDITY) and unique identifier (UID). The triple of mailbox
101 name, UIDVALIDITY, and UID is guaranteed to be immutable.
103 [RFC4315] defines a COPYUID response that allows a client that copies
104 messages to know the mapping between the UIDs in the source and
105 destination mailboxes and, hence, update its local cache.
107 If a mailbox is successfully renamed by a client, that client will
108 know that the same messages exist in the destination mailbox name as
109 previously existed in the source mailbox name.
114Gondwana Standards Track [Page 2]
116RFC 8474 IMAP ObjectID September 2018
119 The result is that the client that copies (or moves [RFC6851])
120 messages or renames a mailbox can update its local cache, but any
121 other client connected to the same store cannot know with certainty
122 that the messages are identical, so it will redownload everything.
124 This extension adds new properties to a message (EMAILID) and mailbox
125 (MAILBOXID). These properties allow a client to quickly identify
126 messages or mailboxes that have been renamed by another client.
128 This extension also adds an optional thread identifier (THREADID) to
129 messages, which can be used by the server to indicate messages that
130 it has identified to be related. A server that does not implement
131 threading will return NIL to all requests for THREADID.
1332. Conventions Used in This Document
135 In examples, "C:" indicates lines sent by a client that is connected
136 to a server. "S:" indicates lines sent by the server to the client.
138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
140 "OPTIONAL" in this document are to be interpreted as described in
141 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
142 capitals, as shown here.
1443. CAPABILITY Identification
146 IMAP servers that support this extension MUST include "OBJECTID" in
147 the response list to the CAPABILITY command.
1494. MAILBOXID Object Identifier
151 The MAILBOXID is a server-allocated unique identifier for each
154 The server MUST return the same MAILBOXID for a mailbox with the same
155 name and UIDVALIDITY.
157 The server MUST NOT report the same MAILBOXID for two mailboxes at
160 The server MUST NOT reuse the same MAILBOXID for a mailbox that does
161 not obey all the invariants that [RFC3501] defines for a mailbox that
162 does not change name or UIDVALIDITY.
170Gondwana Standards Track [Page 3]
172RFC 8474 IMAP ObjectID September 2018
175 The server MUST keep the same MAILBOXID for the source and
176 destination when renaming a mailbox in a way that keeps the same
177 messages (but see [RFC3501] for the special case regarding the
178 renaming of INBOX, which is treated as creating a new mailbox and
179 moving the messages).
1814.1. New Response Code for CREATE
183 This document extends the CREATE command to have the response code
184 MAILBOXID on successful mailbox creation.
186 A server advertising the OBJECTID capability MUST include the
187 MAILBOXID response code in the tagged OK response to all successful
190 Syntax: "MAILBOXID" SP "(" objectid ")"
192 Response code in tagged OK response for successful CREATE command.
197 S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Completed
199 S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)] Completed
201 S: 5 NO Mailbox already exists
2034.2. New OK Untagged Response for SELECT and EXAMINE
205 This document adds a new untagged response code to the SELECT and
208 A server advertising the OBJECTID capability MUST return an untagged
209 OK response with the MAILBOXID response code on all successful SELECT
210 and EXAMINE commands.
212 Syntax: "OK" SP "[" "MAILBOXID" SP "(" objectid ")" "]" SP text
214 Untagged OK response to SELECT or EXAMINE.
220 S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok
222 S: 27 OK [READ-WRITE] Completed
226Gondwana Standards Track [Page 4]
228RFC 8474 IMAP ObjectID September 2018
2314.3. New Attribute for STATUS
233 This document adds the MAILBOXID attribute to the STATUS command
234 using the extended syntax defined in [RFC4466].
236 A server that advertises the OBJECTID capability MUST support the
237 MAILBOXID status attribute.
241 The attribute in the STATUS command.
243 Syntax: "MAILBOXID" SP "(" objectid ")"
245 The response item in the STATUS response contains the ObjectID
246 assigned by the server for this mailbox.
250 C: 6 status foo (mailboxid)
251 S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
253 C: 7 status bar (mailboxid)
254 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
256 C: 8 rename foo renamed
257 S: * OK rename foo renamed
259 C: 9 status renamed (mailboxid)
260 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
262 C: 10 status bar (mailboxid)
263 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
266 When the LIST-STATUS IMAP capability defined in [RFC5819] is also
267 available, the STATUS command can be combined with the LIST command.
271 C: 11 list "" "*" return (status (mailboxid))
272 S: * LIST (\HasNoChildren) "." INBOX
273 S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))
274 S: * LIST (\HasNoChildren) "." bar
275 S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
276 S: * LIST (\HasNoChildren) "." renamed
277 S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
278 S: 11 OK Completed (0.001 secs 3 calls)
282Gondwana Standards Track [Page 5]
284RFC 8474 IMAP ObjectID September 2018
2875. EMAILID Object Identifier and THREADID Correlator
2895.1. EMAILID Identifier for Identical Messages
291 The EMAILID data item is an ObjectID that uniquely identifies the
292 content of a single message. Anything that must remain immutable on
293 a {name, uidvalidity, uid} triple must also be the same between
294 messages with the same EMAILID.
296 The server MUST return the same EMAILID for the same triple; hence,
297 EMAILID is immutable.
299 The server MUST return the same EMAILID as the source message for the
300 matching destination message in the COPYUID pairing after a COPY or
301 MOVE command [RFC6851].
303 The server MAY assign the same EMAILID as an existing message upon
304 APPEND (e.g., if it detects that the new message has exactly
305 identical content to that of an existing message).
307 NOTE: EMAILID only identifies the immutable content of the message.
308 In particular, it is possible for different messages with the same
309 EMAILID to have different keywords. This document does not specify a
310 way to STORE by EMAILID.
3125.2. THREADID Identifier for Related Messages
314 The THREADID data item is an ObjectID that uniquely identifies a set
315 of messages that the server believes should be grouped together when
318 THREADID calculation is generally based on some combination of
319 References, In-Reply-To, and Subject, but the exact logic is left up
320 to the server implementation. [RFC5256] describes some algorithms
321 that could be used; however, this specification does not mandate any
324 The server MUST return the same THREADID for all messages with the
327 The server SHOULD return the same THREADID for related messages, even
328 if they are in different mailboxes; for example, messages that would
329 appear in the same thread if they were in the same mailbox SHOULD
330 have the same THREADID, even if they are in different mailboxes.
332 The server MUST NOT change the THREADID of a message once reported.
338Gondwana Standards Track [Page 6]
340RFC 8474 IMAP ObjectID September 2018
343 THREADID is OPTIONAL; if the server doesn't support THREADID or is
344 unable to calculate relationships between messages, it MUST return
345 NIL to all FETCH responses for the THREADID data item, and a SEARCH
346 for THREADID MUST NOT match any messages.
348 The server MUST NOT use the same ObjectID value for both EMAILIDs and
349 THREADIDs. If they are stored with the same value internally, the
350 server can generate prefixed values (as shown in the examples below
351 with M and T prefixes) to avoid clashes.
3535.3. New Message Data Items in FETCH and UID FETCH Commands
355 This document defines two FETCH items:
359 The EMAILID message data item causes the server to return EMAILID
360 FETCH response data items.
364 The THREADID message data item causes the server to return THREADID
365 FETCH response data items.
367 This document defines the following responses:
369 Syntax: "EMAILID" SP "(" objectid ")"
371 The EMAILID response data item contains the server-assigned ObjectID
374 Syntax: "THREADID" SP "(" objectid ")"
376 The THREADID response data item contains the server-assigned ObjectID
377 for the set of related messages to which this message belongs.
379 Syntax: "THREADID" SP nil
381 The NIL value is returned for the THREADID response data item when
382 the server mailbox does not support THREADID calculation.
394Gondwana Standards Track [Page 7]
396RFC 8474 IMAP ObjectID September 2018
401 C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733}
404 Message-ID: <fake.1521475657.54797@example.com>
406 S: 5 OK [APPENDUID 1521475658 1] Completed
408 C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793}
410 Subject: Re: Message A
411 Message-ID: <fake.1521475657.21213@example.org>
412 References: <fake.1521475657.54797@example.com>
414 S: 11 OK [APPENDUID 1521475658 2] Completed
416 C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736}
419 Message-ID: <fake.1521475657.60280@example.com>
421 S: 17 OK [APPENDUID 1521475658 3] Completed
423 C: 22 fetch 1:* (emailid threadid)
424 S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
425 S: * 2 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
426 S: * 3 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
427 S: 22 OK Completed (0.000 sec)
430 S: * OK [COPYUID 1521475659 2 1] Completed
434 C: 24 fetch 1:* (emailid threadid)
435 S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
436 S: * 2 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
437 S: 24 OK Completed (0.000 sec)
442 S: 25 OK [READ-WRITE] Completed
443 C: 26 fetch 1:* (emailid threadid)
444 S: * 1 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
445 S: 26 OK Completed (0.000 sec)
450Gondwana Standards Track [Page 8]
452RFC 8474 IMAP ObjectID September 2018
455 Example: (no THREADID support)
457 C: 26 fetch 1:* (emailid threadid)
458 S: * 1 FETCH (EMAILID (M00000001) THREADID NIL)
459 S: * 2 FETCH (EMAILID (M00000002) THREADID NIL)
460 S: 26 OK Completed (0.000 sec)
4636. New Filters on SEARCH Command
465 This document defines the filters EMAILID and THREADID on the SEARCH
468 Syntax: "EMAILID" SP objectid
470 Messages whose EMAILID is exactly the specified ObjectID.
472 Syntax: "THREADID" SP objectid
474 Messages whose THREADID is exactly the specified ObjectID.
476 Example: (as if run before the MOVE shown above when the mailbox had
479 C: 27 search emailid M6d99ac3275bb4e
481 S: 27 OK Completed (1 msgs in 0.000 secs)
482 C: 28 search threadid T64b478a75b7ea9
484 S: 28 OK Completed (2 msgs in 0.000 secs)
488 The following syntax specification uses the Augmented Backus-Naur
489 Form (ABNF) [RFC5234] notation. Elements not defined here can be
490 found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and
491 IMAP ABNF extensions [RFC4466] specifications.
493 Except as noted otherwise, all alphabetic characters are case
494 insensitive. The use of uppercase or lowercase characters to define
495 token strings is for editorial clarity only. Implementations MUST
496 accept these strings in a case-insensitive fashion.
498 Please note specifically that ObjectID values are case sensitive.
506Gondwana Standards Track [Page 9]
508RFC 8474 IMAP ObjectID September 2018
511 capability =/ "OBJECTID"
513 fetch-att =/ "EMAILID" / "THREADID"
515 fetch-emailid-resp = "EMAILID" SP "(" objectid ")"
516 ; follows tagged-ext production from [RFC4466]
518 fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil )
519 ; follows tagged-ext production from [RFC4466]
521 msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp
523 objectid = 1*255(ALPHA / DIGIT / "_" / "-")
524 ; characters in object identifiers are case
527 resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
528 ; incorporated before the expansion rule of
529 ; atom [SP 1*<any TEXT-CHAR except "]">]
530 ; that appears in [RFC3501]
532 search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid
534 status-att =/ "MAILBOXID"
536 status-att-val =/ "MAILBOXID" SP "(" objectid ")"
537 ; follows tagged-ext production from [RFC4466]
5398. Implementation Considerations
5418.1. Assigning Object Identifiers
543 All ObjectID values are allocated by the server.
545 In the interest of reducing the possibilities of encoding mistakes,
546 ObjectIDs are restricted to a safe subset of possible byte values; in
547 order to allow clients to allocate storage, they are restricted in
550 An ObjectID is a string of 1 to 255 characters from the following set
551 of 64 codepoints: a-z, A-Z, 0-9, _, -. These characters are safe to
552 use in almost any context (e.g., filesystems, URIs, IMAP atoms).
553 These are the same characters defined as base64url in [RFC4648].
562Gondwana Standards Track [Page 10]
564RFC 8474 IMAP ObjectID September 2018
567 For maximum safety, servers should also follow defensive allocation
568 strategies to avoid creating risks where glob completion or data type
569 detection may be present (e.g., on filesystems or in spreadsheets).
570 In particular, it is wise to avoid:
572 o IDs starting with a dash
574 o IDs starting with digits
576 o IDs that contain only digits
578 o IDs that differ only by ASCII case (for example, A vs. a)
580 o the specific sequence of three characters NIL in any case (because
581 this sequence can be confused with the IMAP protocol expression of
584 A good solution to these issues is to prefix every ID with a single
585 alphabetical character.
5878.2. Interaction with Special Cases
589 The case of RENAME INBOX may need special handling because it has
590 special behavior, as defined in [RFC3501], Section 6.3.5.
592 It is advisable (though not required) to have MAILBOXID be globally
593 unique, but it is only required to be unique within messages offered
594 to a single client login to a single server hostname. For example, a
595 proxy that aggregates multiple independent servers MUST NOT advertise
596 the OBJECTID capability unless it can guarantee that different
597 objects will never use the same identifiers, even if backend object
602 Servers that implement both RFC 6154 and this specification should
603 optimize their execution of commands like UID SEARCH OR EMAILID 1234
606 Clients can assume that searching the all-mail mailbox using OR/
607 EMAILID or OR/THREADID is a fast way to find messages again if some
608 other client has moved them out of the mailbox where they were
611 Clients that cache data offline should fetch the EMAILID of all new
612 messages to avoid redownloading already-cached message details.
618Gondwana Standards Track [Page 11]
620RFC 8474 IMAP ObjectID September 2018
623 Clients should fetch the MAILBOXID for any new mailboxes before
624 discarding cache data for any mailbox that is no longer present on
625 the server so that they can detect renames and avoid redownloading
6288.4. Advice to Client Implementers
630 In cases of server failure and disaster recovery, or misbehaving
631 servers, it is possible that a client will be sent invalid
632 information, e.g., identical ObjectIDs or ObjectIDs that have changed
633 where they MUST NOT change according to this document.
635 In a case where a client detects inconsistent ObjectID responses from
636 a server, it SHOULD fall back to relying on the guarantees of RFC
637 3501. For simplicity, a client MAY instead choose to discard its
638 entire cache and resync all state from the server.
640 Client authors protecting against server misbehavior MUST ensure that
641 their design cannot get into an infinite loop of discarding cache and
642 fetching the same data repeatedly without user interaction.
6449. Future Considerations
646 This extension is intentionally defined to be compatible with the
647 data model in [JMAP-MAIL].
649 A future extension could be proposed to give a way to SELECT a
650 mailbox by MAILBOXID rather than name.
652 A future extension to [RFC5228] could allow fileinto by MAILBOXID
655 An extension to allow fetching message content directly via EMAILID
656 and message listings by THREADID could be proposed.
65810. IANA Considerations
660 IANA has added "OBJECTID" to the "IMAP Capabilities" registry located
661 at <https://www.iana.org/assignments/imap-capabilities> with a
662 reference to this document.
664 IANA has added "MAILBOXID" to the "IMAP Response Codes" registry
665 located at <https://www.iana.org/assignments/imap-response-codes>
666 with a reference to this document.
674Gondwana Standards Track [Page 12]
676RFC 8474 IMAP ObjectID September 2018
67911. Security Considerations
681 It is strongly advised that servers generate ObjectIDs that are safe
682 to use as filesystem names and unlikely to be autodetected as
683 numbers. See implementation considerations.
685 If a digest is used for ID generation, it must have a collision-
686 resistant property, so server implementations are advised to monitor
687 current security research and choose secure digests. As the IDs are
688 generated by the server, it will be possible to migrate to a new hash
689 by just using the new algorithm when creating new IDs. This is
690 particularly true if a prefix is used on each ID, which can be
691 changed when the algorithm changes.
693 The use of a digest for ID generation may be used as proof that a
694 particular sequence of bytes was seen by the server. However, this
695 is only a risk if IDs are leaked to clients who don't have permission
696 to fetch the data directly. Servers that are expected to handle
697 highly sensitive data should consider this when choosing how to
700 See also the security considerations in [RFC3501], Section 11.
70412.1. Normative References
706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
707 Requirement Levels", BCP 14, RFC 2119,
708 DOI 10.17487/RFC2119, March 1997,
709 <https://www.rfc-editor.org/info/rfc2119>.
711 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
712 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
713 <https://www.rfc-editor.org/info/rfc3501>.
715 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
716 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
717 December 2005, <https://www.rfc-editor.org/info/rfc4315>.
719 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
720 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
721 <https://www.rfc-editor.org/info/rfc4466>.
723 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
724 Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
725 January 2008, <https://www.rfc-editor.org/info/rfc5228>.
730Gondwana Standards Track [Page 13]
732RFC 8474 IMAP ObjectID September 2018
735 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
736 Specifications: ABNF", STD 68, RFC 5234,
737 DOI 10.17487/RFC5234, January 2008,
738 <https://www.rfc-editor.org/info/rfc5234>.
740 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
741 Protocol - SORT and THREAD Extensions", RFC 5256,
742 DOI 10.17487/RFC5256, June 2008,
743 <https://www.rfc-editor.org/info/rfc5256>.
745 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for
746 Returning STATUS Information in Extended LIST", RFC 5819,
747 DOI 10.17487/RFC5819, March 2010,
748 <https://www.rfc-editor.org/info/rfc5819>.
750 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message
751 Access Protocol (IMAP) - MOVE Extension", RFC 6851,
752 DOI 10.17487/RFC6851, January 2013,
753 <https://www.rfc-editor.org/info/rfc6851>.
755 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
756 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
757 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
75912.2. Informative References
762 Jenkins, N. and C. Newman, "JMAP for Mail", Work in
763 Progress, draft-ietf-jmap-mail-07, August 2018.
765 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
766 Unique IDentifier (UUID) URN Namespace", RFC 4122,
767 DOI 10.17487/RFC4122, July 2005,
768 <https://www.rfc-editor.org/info/rfc4122>.
770 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
771 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
772 <https://www.rfc-editor.org/info/rfc4648>.
786Gondwana Standards Track [Page 14]
788RFC 8474 IMAP ObjectID September 2018
791Appendix A. Ideas for Implementing Object Identifiers
793 Ideas for calculating MAILBOXID:
795 o Universally Unique Identifier (UUID) [RFC4122]
797 o Server-assigned sequence number (guaranteed not to be reused)
799 Ideas for implementing EMAILID:
801 o Digest of message content (RFC822 bytes) -- expensive unless
806 o Server-assigned sequence number (guaranteed not to be reused)
808 Ideas for implementing THREADID:
810 o Derive from EMAILID of first seen message in the thread.
814 o Server-assigned sequence number (guaranteed not to be reused)
816 There is a need to index and look up reference/in-reply-to data at
817 message creation to efficiently find matching messages for threading.
818 Threading may be either across mailboxes or within each mailbox only.
819 The server has significant leeway here.
823 The author would like to thank the EXTRA working group at IETF for
824 feedback and advice -- in particular, Arnt Gulbrandsen, Brandon Long,
825 Chris Newman, and Josef Sipek.
827 This document drew inspiration from the Gmail X-GM-THRID and X-GM-
828 MSGID implementations as currently defined at
829 <https://developers.google.com/gmail/imap/imap-extensions>, as well
830 as the X-GUID implementation in the Dovecot server.
842Gondwana Standards Track [Page 15]
844RFC 8474 IMAP ObjectID September 2018
849 Bron Gondwana (editor)
851 Level 2, 114 William St
855 Email: brong@fastmailteam.com
856 URI: https://www.fastmail.com
898Gondwana Standards Track [Page 16]