idnits 2.17.1 draft-ietf-morg-inthread-01.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 date (July 8, 2010) is 5041 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Arnt Gulbrandsen 3 Internet-Draft July 8, 2010 4 Intended Status: Proposed Standard 6 The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions 7 draft-ietf-morg-inthread-01.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 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft expires in January 2011. 31 Copyright Notice 33 Copyright (c) 2010 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with 41 respect to this document. Code Components extracted from this 42 document must include Simplified BSD License text as described in 43 Section 4.e of the Trust Legal Provisions and are provided without 44 warranty as described in the Simplified BSD License. 46 Abstract 48 The SEARCH=INTHREAD extension extends the IMAP SEARCH command to 49 operate on threads as well as individual messages. Other commands 50 which search are implicitly extended. This allows clients to perform 51 searches such as "find all threads that mention schemata", rather 52 than just "find all single messages that mention schemata". 54 The THREAD=REFS extension provides a threading algorithm using 55 (almost) only the References header field for use with the IMAP 56 THREAD command. 58 1. Conventions Used in This Document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 Formal syntax is defined by [RFC5234]. 66 Example lines prefaced by "C:" are sent by the client and ones 67 prefaced by "S:" by the server. The five characters [...] means that 68 something has been elided. 70 2. Overview 72 This document defines two related extensions. 74 The THREAD=REFS extension defined a fairly pure References-based 75 (see [RFC5322] section 3.6.4) threading algorithm for use with the 76 THREAD command (see [RFC5256]) and with SEARCH=INTHREAD. 78 An IMAP server (see [RFC3501]) that supports the THREAD=REFS 79 extension MUST announce THREAD=REFS as capabilities. The THREAD=REFS 80 extension adds no new commands and responses, only a new thread 81 algorithm. 83 The SEARCH=INTHREAD extension extends the IMAP SEARCH command to 84 operate on threads as well as individual messages. Other commands 85 which search are implicitly extended. SEARCH=INTHREAD requires that 86 servers implement THREAD=REFS too. 88 An IMAP server that supports SEARCH=INTHREAD announces both 89 SEARCH=INTHREAD and THREAD=REFS as capabilities. The SEARCH=INTHRAD 90 extension adds no new commands and responses, but adds two new 91 search-keys, INTHREAD and MESSAGEID, and one search return option, 92 THREAD=REFS. 94 3. New Search Keys etc. 96 This document defines a new search key which finds all messages in a 97 thread where at least one message matches another (specified) search 98 key, and a helper which matches a message given its message-id. 100 3.1. The INTHREAD Search Key 102 INTHREAD takes one argument, which is another search key. 104 If the argument matches a message, then INTHREAD matches all the 105 message in the same thread as that message. 107 This command finds all messages in an entire thread concerning the 108 meetings where fizzle was discussed: 110 C: a UID SEARCH INTHREAD (SUBJECT meeting BODY fizzle) 112 This command threads all threads containing at least one message 113 from fred@example.com: 115 C: a UID THREAD REFS utf-8 INTHREAD FROM 117 3.2. The MESSAGEID Search Key 119 The MESSAGEID search key takes a sigle argument, and matches a 120 message if that message's message-id is the same as the argument. 122 This command finds all in the same thread as 123 <432.123.321@example.com>: 125 C: a UID SEARCH INTHREAD MESSAGEID 126 "<4321.1234.321@example.com>" 128 Note that in the past, some message-ids contained needless quoting. 129 Up to around 2001, a message might have the following Message-ID: 131 Message-ID: <"432.123.321"@example.com> 133 A reply might remove the unnecessary quotes: 135 References: <432.123.321@example.com> 137 Although such message-id quoting ist still permitted, the author of 138 this document has not found evidence of such quoting since 2001. 139 This document does not make any recommendation about how to handle 140 quoted left-hand-sides. 142 3.3. The THREAD=* Search Return Option(s) 144 The THREAD=* search return options enables the client to select 145 which threading algorithm the server uses when processing INTHREAD 146 as part of a SEARCH command. If THREAD=* isn't specified, then the 147 default for the SEARCH command is THREAD=REFS. 149 When the server processes a THREAD command, it uses the algorithm 150 specified by the client. 152 I can't think of a good example (or use case) for a non-default use 153 of this. 155 4. The THREAD=REFS Thread Algorithm 157 The THREAD=REFS thread algorithm is defined as the part of 158 THREAD=REFERENCES (see [RFC5256]) which concerns itself with the 159 References, In-Reply-To and Message-ID fields. THREAD=REFS ignores 160 Subject. 162 THREAD=REFS sorts threads by the most recent INTERNALDATE in each 163 thread, replacing THREAD=REFERENCES step (4). This means that when a 164 new message arrives, its thread becomes the latest thread. (Note 165 that while threads are sorted by arrival date, messages within a 166 thread are sorted by sent date, just as for THREAD=REFERENCES.) 168 This document defines THREAD=REFS because THREAD=REFERENCES is too 169 inclusive for the INTHREAD search key. For example, independent 170 threads that happen to have the same subject field (such as "Agenda 171 for Friday's meeting", "Web site updated" or "Message delivery 172 failed") are grouped into one thread by THREAD=REFERENCES. 174 It is explicitly permitted for the server to persistently store 175 threading information, even if this causes the server to return 176 different information than it would otherwise. This can happen if 177 the first messages in a thread are deleted, for example. 179 5. Formal Syntax 181 The following syntax specification uses the Augmented Backus-Naur 182 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 183 the non-terminals "capability", "search-key" and "string", [RFC4466] 184 defines "search-return-opt", [RFC5256] defines "thread-alg". 186 Except as noted otherwise, all alphabetic characters are case- 187 insensitive. The use of upper or lower case characters to define 188 token strings is for editorial clarity only. Implementations MUST 189 accept these strings in a case-insensitive fashion. 191 capability =/ "SEARCH=INTHREAD" / "THREAD=REFS" 193 search-key =/ "INTHREAD" SP search-key / "MESSAGEID" SP string 195 thread-alg =/ "REFS" 197 search-return-opt =/ "THREAD=" thread-alg 199 6. Security Considerations 201 This document is believed not to have any security implications. 203 7. IANA Considerations 205 The IANA is requested to add SEARCH=INTHREAD and THREAD=REFS to the 206 list of IMAP extensions, 207 http://www.iana.org/assignments/imap4-capabilities. 209 8. Acknowledgements 211 The name THREAD=REFS was suggested by Cyrus Daboo. Dave Cridland, 212 Alexey Menikov and particularly Timo Sirainen have helped with the 213 document. 215 9. Normative References 217 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 218 Requirement Levels", RFC 2119, Harvard University, March 219 1997. 221 [RFC3501] Crispin, "Internet Message Access Protocol - Version 222 4rev1", RFC 3501, University of Washington, June 2003. 224 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 225 RFC 4466, Isode Ltd., April 2006. 227 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 228 Specifications: ABNF", RFC 5234, January 2008. 230 [RFC5256] Crispin, Murchison, "INTERNET MESSAGE ACCESS PROTOCOL - 231 SORT AND THREAD EXTENSIONS", RFC 5256, Panda Programming, 232 June 2008. 234 [RFC5322] Resnick, "Internet Message Format", RFC 5322, Qualcomm, 235 October 2008. 237 10. Author's Address 239 Arnt Gulbrandsen 240 Schweppermannstr. 8 241 D-81671 Muenchen 242 Germany 244 Email: arnt@gulbrandsen.priv.no 245 (RFC Editor: Please delete everything after this point) 247 11. Open Issues 249 I removed THREADROOT and THREADLEAF. Put them back in? I didn't 250 actually implement them (it's now 14 months since I implemented 251 INTHREAD), so I dropped them from the draft now, on the theory that 252 the're insufficiently justified. 254 I left the THREAD= search return option, but I haven't implemented 255 it either. I don't see any use cases for anything other than the 256 default. (At the moment there isn't an example, which is really 257 another way of saying "no use cases".) I want to drop it. 259 It's not clear to me that the MESSAGEID search-key is worth the 260 bother. HEADER Message-Id "" searches for a substring and 261 MESSAGEID "" for a complete message-id. In a sample of a 262 half-million recent messages, none of the message-ids contained 263 embededded greater-than or less-than signs, so it's hard to imagine 264 any practical effects of treating the two searches identically. 266 12. Changes since -00 268 - The IANA asked me to specify the IANA registry exactly 270 - Boilerplate updates - IETF Trust and so on. 272 Changes since -01 274 - Added THREADROOT, THREADLEAF and MESSAGEID 276 - Fixed the typo 278 Changes since -02 280 - Specified thread algorithm per-command, generally using a search 281 return option. 283 - Defined THREADROOT and THREADLEAF robustly. 285 - Required that the server implement THREAD=REFS if it implements 286 SEARCH=INTHREAD. 288 - Use In-Reply-To as THREAD=REFERENCES, since Timo prefers that and 289 I don't mind. 291 - Use Date as T=R does. Hm? Good idea? 293 Changes since -03 295 - Boilerplate updates for 5377 and blah 297 Changes since -03 299 - Sort threads by the most recent date in each thread, so that new 300 messages arriving makes a thread new again. 302 Changes since d-g-i-i-04 304 - Define "most recent thread" by arrival date, not sender date. 305 Suits typical client use better. When reading a thread, you want 306 to read messages as ordered by the senders, but the most recent 307 thread should be the one which arrived in your mailbox most 308 recently. 310 - Rename to be a WG draft. 312 Changes since -00 314 - I had a bit of an SCM disaster with my laptop, desktop and git. I 315 hope I resolved it well. My apologies if dropped something. 317 - Better wording for the INTHREAD search key 319 - Message-id turned into an IMAP string. 321 - Elaborated a little on message-id equality. The text leaves it up 322 to the server whether it will normalize. (The last program to 323 generate quotes in message-ids was, AFAICT, procmail/formail, and 324 it quit around 2001. The changelog does not say why. I asked 325 Philip and he can't remember either. Up to 2001 some respondents 326 normalized procmail's message-ids and some (most?) didn't.) 328 - Remove THREADROOT and THREADLEAF. Note my desire to remove THREAD= 329 and perhaps MESSAGEID.