idnits 2.17.00 (12 Aug 2021) /tmp/idnits16191/draft-gulbrandsen-imap-inthread-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2008) is 4904 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Arnt Gulbrandsen 3 Internet-Draft Oryx Mail Systems GmbH 4 Intended Status: Proposed Standard December 15, 2008 6 The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions 7 draft-gulbrandsen-imap-inthread-05.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with 12 the provisions of BCP 78 and BCP 79. 14 Copyright (c) 2008 IETF Trust and the persons identified as the 15 document authors. All rights reserved. 17 This document is subject to BCP 78 and the IETF Trust's Legal 18 Provisions Relating to IETF Documents 19 (http://trustee.ietf.org/license-info) in effect on the date of 20 publication of this document. Please review these documents 21 carefully, as they describe your rights and restrictions with 22 respect to this document. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 36 Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft expires in June 2009. 41 Internet-draft December 2008 43 Abstract 45 The SEARCH=INTHREAD extension extends the IMAP SEARCH command to 46 operate on threads as well as individual messages. Other commands 47 which search are implicitly extended. 49 The THREAD=REFS extension provides a threading algorithm using 50 (almost) only the References header field for use with the IMAP 51 THREAD command. 53 1. Conventions Used in This Document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 Formal syntax is defined by [RFC5234]. 61 Example lines prefaced by "C:" are sent by the client and ones 62 prefaced by "S:" by the server. The five characters [...] means that 63 something has been elided. 65 2. Overview 67 This document defines two related extensions. 69 The THREAD=REFS extension defined a fairly pure References-based 70 (see [RFC5322] section 3.6.4) threading algorithm for use with the 71 THREAD command (see [RFC5256]) and with SEARCH=INTHREAD. 73 An IMAP server (see [RFC3501]) that supports the THREAD=REFS 74 extension MUST announce THREAD=REFS as capabilities. This extension 75 adds no new commands and responses, only a new thread algorithm. 77 The SEARCH=INTHREAD extension extends the IMAP SEARCH command to 78 operate on threads as well as individual messages. Other commands 79 which search are implicitly extended. SEARCH=INTHREAD requires that 80 servers implement THREAD=REFS too. 82 An IMAP server that supports SEARCH=INTHREAD MUST announce both 83 SEARCH=INTHREAD and THREAD=REFS as capabilities. This extension adds 84 no new commands and responses, but adds four new search-keys, 85 INTHREAD, THREADROOT, THREADLEAF and MESSAGEID, and least one search 86 return option, THREAD=REFS. 88 Internet-draft December 2008 90 3. New Search Keys 92 This document defines three new search keys which operate on 93 threads: One to find all messages in a thread where at least one 94 message matches another search key, one to find the roots of threads 95 and one to find the leaves. It also defines a helper which matches a 96 message given its message-id. 98 3.1. The INTHREAD Search Key 100 INTHREAD takes one argument, which is another search key. 102 The INTHREAD search-key matches a message if its subsidiary search- 103 key matches at least one message in the same thread as the message. 105 This command finds all messages in an entire thread concerning the 106 meetings where fizzle was discussed: 108 C: a UID SEARCH INTHREAD (SUBJECT meeting BODY fizzle) 110 This command threads all threads containing at least one message 111 from fred@example.com: 113 C: a UID THREAD REFS utf-8 INTHREAD FROM 115 3.2. The THREADROOT Search Key 117 The THREADROOT search key matches a message if that message does not 118 have any parent message in the same mailbox according to the active 119 threading algorithm (see section 3.5). 121 This command finds the roots of all threads containing unread 122 messages: 124 C: a UID SEARCH THREADROOT INTHREAD UNSEEN 126 3.3. The THREADLEAF Search Key 128 The THREADLEAF search key matches a message if that message has no 129 child message in the same mailbox, according to the active threading 130 algorithm. 132 Note that THEADLEAF interacts badly with THREAD=ORDEREDSUBJECT. 133 THREAD=ORDEREDSUBJECT is defined such that every message is either a 134 root or a leaf, there are no intermediate nodes. 136 Internet-draft December 2008 138 This command finds all messages that were (also) sent to me, and to 139 which noone has answered: 141 C: a UID SEARCH THREADLEAF OR TO CC 142 144 3.4. The MESSAGEID Search Key 146 The MESSAGEID search key takes a sigle argument, and matches a 147 message if that message's normalized nessage-id is the same as the 148 argument. 150 This command finds all in the same thread as 151 <4321.1234321@example.com>: 153 C: a UID SEARCH INTHREAD MESSAGEID <4321.1234321@example.com> 155 3.5. The THREAD=* Search Return Option(s) 157 The THREAD=* search return options enables the client to select 158 which threading algorithm the server uses when processing INTHREAD, 159 THREADROOT and THREADLEAF as part of a SEARCH command. If THREAD=* 160 isn't specified, then the default for the SEARCH command is 161 THREAD=REFS. 163 When the server processes a THREAD command, it uses the algorithm 164 specified by the client. 166 This command sorts the messages by subject and returns the first 167 message with each subject, disregarding "fwd", "re" and other 168 paraphernalia: 170 C: a UID SEARCH RETURN (THREAD=ORDEREDSUBJECT) THREADROOT 172 4. The THREAD=REFS Thread Algorithm 174 The THREAD=REFS thread algorithm is defined as the part of 175 THREAD=REFERENCES (see [RFC5256]) which concerns itself with the 176 References, In-Reply-To and Message-ID fields. It has the following 177 three differences from THREAD=REFERENCES: 179 THREAD=REFS ignores Subject. Where THREAD=REFERENCES groups 180 independent threads into one thread when they have same subject 181 field (such as "Agenda for Friday's meeting", "Web site updated" or 182 "Message delivery failed"), THREAD=REFS keeps them apart. 184 Internet-draft December 2008 186 THREAD=REFS sorts by the most recent date in each thread, replacing 187 step (4) of THREAD=REFERENCES. This means that when a new message 188 arrives, its thread becomes the latest thread. A message's date is 189 computed as specified in [RFC5256] section 2.2. 191 It is explicitly permitted for the server to persistently store 192 threading information, even if this causes the server to return 193 different information than it would otherwise. This can happen if 194 the first messages in a thread are deleted, for example. 196 5. Formal Syntax 198 The following syntax specification uses the Augmented Backus-Naur 199 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 200 the non-terminals "capability" and "search-key", [RFC4466] defines 201 "search-return-opt", [RFC5256] defines "thread-alg", and [RFC5322] 202 defines "id-left" and "id-right". 204 Except as noted otherwise, all alphabetic characters are case- 205 insensitive. The use of upper or lower case characters to define 206 token strings is for editorial clarity only. Implementations MUST 207 accept these strings in a case-insensitive fashion. 209 capability =/ "SEARCH=INTHREAD" / "THREAD=REFS" 211 search-key =/ "INTHREAD" SP search-key / "MESSAGEID" SP "<" 212 id-left "@" id-right ">" / "THREADROOT" / 213 "THREADLEAF" 215 thread-alg =/ "REFS" 217 search-return-opt =/ "THREAD=" thread-alg 219 6. Security Considerations 221 This document is believed not to have any security implications. 223 7. IANA Considerations 225 The IANA is requested to add SEARCH=INTHREAD and THREAD=REFS to the 226 list of IMAP extensions, 227 http://www.iana.org/assignments/imap4-capabilities. 229 8. Acknowledgements 230 Internet-draft December 2008 232 The name THREAD=REFS was suggested by Cyrus Daboo. Dave Cridland, 233 Alexey Menikov and particularly Timo Sirainen have helped with the 234 document. 236 9. Normative References 238 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 239 Requirement Levels", RFC 2119, Harvard University, March 240 1997. 242 [RFC3501] Crispin, "Internet Message Access Protocol - Version 243 4rev1", RFC 3501, University of Washington, June 2003. 245 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 246 RFC 4466, Isode Ltd., April 2006. 248 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 249 Specifications: ABNF", RFC 5234, January 2008. 251 [RFC5256] Crispin, Murchison, "INTERNET MESSAGE ACCESS PROTOCOL - 252 SORT AND THREAD EXTENSIONS", RFC 5256, Panda Programming, 253 June 2008. 255 [RFC5322] Resnick, "Internet Message Format", RFC 5322, Qualcomm, 256 October 2008. 258 10. Author's Address 260 Arnt Gulbrandsen 261 Oryx Mail Systems GmbH 262 Schweppermannstr. 8 263 D-81671 Muenchen 264 Germany 266 Fax: +49 89 4502 9758 268 Email: arnt@oryx.com 270 Internet-draft December 2008 272 (RFC Editor: Please delete everything after this point) 274 Open Issues 276 None. 278 Changes since -00 280 - The IANA asked me to specify the IANA registry exactly 282 - Boilerplate updates - IETF Trust and so on. 284 Changes since -01 286 - Added THREADROOT, THREADLEAF and MESSAGEID 288 - Fixed the typo 290 Changes since -02 292 - Specified thread algorithm per-command, generally using a search 293 return option. 295 - Defined THREADROOT and THREADLEAF robustly. 297 - Required that the server implement THREAD=REFS if it implements 298 SEARCH=INTHREAD. 300 - Use In-Reply-To as THREAD=REFERENCES, since Timo prefers that and 301 I don't mind. 303 - Use Date as T=R does. Hm? Good idea? 305 Changes since -03 307 - Boilerplate updates for 5377 and blah 309 Changes since -04 311 - Sort threads by the most recent date in each thread, so that new 312 messages arriving makes a thread new again. 314 Internet-draft December 2008 316 - Generally rephrase the T=R section, so that the requirements line 317 up textually 319 - Avoid the word extant. It's too odd, using it is begging for a 320 misunderstanding.