idnits 2.17.1 draft-ietf-imapext-thread-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([WSP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 79: '...onnected clients MUST use exactly this...' RFC 2119 keyword, line 227: '...plementations of THREAD MUST implement...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2000) is 8830 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) -- Missing reference section? 'WSP' on line 212 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Crispin 2 Internet Draft: IMAP THREAD University of Washington 3 Document: internet-drafts/draft-ietf-imapext-thread-00.txt February 2000 5 INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net 31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 32 Rim). 34 A revised version of this draft document will be submitted to the RFC 35 editor as a Proposed Standard for the Internet Community. 37 Discussion and suggestions for improvement are requested, and should 38 be sent to ietf-imapext@IMC.ORG. This document will expire before 5 39 July 2000. Distribution of this memo is unlimited. 41 Abstract 43 This document describes the server-based threading extension to the 44 IMAP4rev1 protocol. This extension provides substantial performance 45 improvements for IMAP clients which offer threaded views. 47 A server which supports this extension indicates this with more or 48 more capability names consisting of "THREAD-" followed by a supported 49 threading algorithm name as described in this document. This 50 provides for future upwards-compatible extensions. 52 Extracted Subject Text 54 Threading algorithms use a version of the subject which has specific 55 subject artifacts of deployed Internet mail software removed. Due to 56 the complexity of these artifacts, the above syntax is ambiguous. 57 The following procedure is followed to determing the actual "base 58 subject": 60 (1) Remove all trailing text of the subject that matches 61 the subj-trailer ABNF, repeat until no more matches are 62 possible. 64 (2) Remove all prefix text of the subject that matches 65 subj-leader. 67 (3) If there is prefix text of the subject that matches 68 subj-blob, and removing that prefix leaves a non-empty 69 subj-base, then remove the prefix text. 71 (4) Repeat (2) and (3) until no matches remain. 73 (5) Convert any RFC 2047 encoded-words in the remaining 74 subj-base to UTF-8. 76 (6) The resulting text is the "base subject" used in the 77 THREAD. 79 All servers and disconnected clients MUST use exactly this algorithm 80 when threading. Otherwise there is potential for a user to get 81 inconsistant results based on whether they are running in connected 82 or disconnected IMAP mode. 84 Additional Commands 86 This command is an extension to the IMAP4rev1 base protocol. 88 The section header is intended to correspond with where it would be 89 located in the main document if it was part of the base 90 specification. 92 6.3.THREAD. THREAD Command 94 Arguments: threading algorithm 95 charset specification 96 searching criteria (one or more) 98 Data: untagged responses: THREAD 100 Result: OK - thread completed 101 NO - thread error: can't thread that charset or 102 criteria 103 BAD - command unknown or arguments invalid 105 The THREAD command is a variant of SEARCH with threading semantics 106 for the results. Thread has two arguments before the searching 107 criteria argument; a threading algorithm, and the searching 108 charset. Note that unlike SEARCH, the searching charset argument 109 is mandatory. 111 There is also a UID THREAD command which corresponds to THREAD the 112 way that UID SEARCH corresponds to SEARCH. 114 The THREAD command first searches the mailbox for messages that 115 match the given searching criteria using the charset argument for 116 the interpretation of strings in the searching criteria. It then 117 returns the matching messages in an untagged THREAD response, 118 threaded according to the specified threading algorithm. Unlike 119 SEARCH, if no messages match the searching criteria in a THREAD 120 command, no untagged THREAD response is returned. 122 The defined threading algorithms are as follows: 124 ORDEREDSUBJECT 125 The ORDEREDSUBJECT threading algorithm is also referred to as 126 "poor man's threading." The searched messages are sorted by 127 subject and then by sent date, equivalent to a "SORT (SUBJECT 128 DATE)". The messages are then split into separate threads, 129 with each thread containing messages with the same extracted 130 subject text. Finally, the threads are sorted by the sent date 131 of the first message in the thread. 133 Example: C: A283 THREAD ORDEREDSUBJECT UTF-8 SINCE 5-AUG-1999 134 S: * THREAD (146 151)(144 145)(155)(147 148 152 135 167)(182)(181)(149)(154)(153)(164 170)(156) 136 (158 161 162)(157 160 163)(159)(183 185)(165) 137 (166)(168)(169)(171)(172)(173)(186)(174)(150) 138 (175)(176)(177 179 184)(178)(180)(187) 139 S: A283 OK THREAD completed 140 C: A284 THREAD ORDEREDSUBJECT US-ASCII TEXT "gewp" 141 S: A284 OK THREAD completed 143 Note: The line breaks in the first client response are for 144 editorial clarity and do not appear in a real THREAD 145 response. 147 Additional Responses 149 This response is an extension to the IMAP4rev1 base protocol. 151 The section heading of this response is intended to correspond with 152 where it would be located in the main document. 154 7.2.THREAD. THREAD Response 156 Data: one or more threads 158 The THREAD response occurs as a result of a THREAD or UID THREAD 159 command. It contains one or more threads. A thread consists of a 160 parenthesized list of thread members. Thread members consist of 161 one or more message numbers until the thread splits into multiple 162 sub-threads, at which point the thread nests into multiple sub- 163 threads. There is no limit to the nesting of threads. 165 The messages numbers refer to those messages that match the search 166 criteria. For THREAD, these are message sequence numbers; for UID 167 THREAD, these are unique identifiers. 169 Example: S: * THREAD (2)(3 6 (4 23)(44 7 96)) 171 In this example, there are two threads. The first thread 172 consists only of message 2. The second thread consists 173 of the messages 3 and 6, after which it splits into two 174 subthreads; the first of which contains messages 4 and 175 23, and the second of which contains messages 44, 7, and 176 96. 178 2 179 ,- 4 - 23 180 3 - 6 -< 181 `- 44 - 7 - 96 183 Formal Syntax of THREAD commands and Responses 185 thread-data = "THREAD" SPACE 1*thread-list 187 thread-list = "(" thread-members / thread-nested ")" 189 thread-members = nz-number *(SP nz-number) [SP thread-nested] 191 thread-nested = 2*thread-list 193 thread = ["UID" SPACE] "THREAD" SP thread-algorthm 194 SP search-charset 1*(SP search-key) 196 thread-algorithm = "ORDEREDSUBJECT" / atom 198 The following syntax describes subject extraction rules (1)-(5): 200 subject = *(subj-leader / subj-blob) subj-base *subj-trailer 202 subj-repeat = "[" 1*DIGIT "]" 204 subj-refwd = ("re" / ("fw" ["d"])) [subj-repeat] ":" 206 subj-leader = subj-refwd / WSP 208 subj-blob = "[" 1*BLOBCHAR "]" *WSP 210 subj-trailer = "(fwd)" / WSP 212 subj-base = NONWSP *([WSP] NONWSP) 214 BLOBCHAR = %x01-5c / %x5e-7f 215 ; any CHAR except ']' 217 NONWSP = %x01-08 / %x0a-1f / %x21-7f 218 ; any CHAR other than WSP 220 Security Considerations 222 Security issues are not discussed in this memo. 224 Internationalization Considerations 226 By default, strings are threaded according to the "minimum sorting 227 collation algorithm". All implementations of THREAD MUST implement 228 the minimum sorting collation algorithm. 230 In the minimum sorting collation algorithm, the 26 Latin alphabetics 231 are sorted in a case-insensitive fashion; that is, "A" and "a" are 232 treated as exact equals. All other characters are sorted according 233 to their octet values, as expressed in UTF-8. No attempt is made to 234 treat composed characters specially. 236 Other sorting collations, and the ability to change the sorting 237 collation, will be defined in a separate document dealing with IMAP 238 internationalization. 240 It is anticipated that there will be a generic Unicode sorting 241 collation, which will provide generic case-insensitivity for 242 alphabetic scripts, specification of composed character handling, and 243 language-specific sorting collations. A server which implements 244 non-default sorting collations will modify its sorting behavior 245 according to the selected sorting collation. 247 Non-English translations of "Re" or "Fw"/"Fwd" are not specified for 248 removal in the extracted subject text process. By specifying that 249 only the English forms of the prefixes are used, it becomes a simple 250 display time task to localize the prefix language for the user. If, 251 on the other hand, prefixes in multiple languages are permitted, the 252 result is a geometrically complex, and ultimately unimplementable, 253 task. In order to improve the ability to support non-English display 254 in Internet mail clients, only the English form of these prefixes 255 should be transmitted in Internet mail messages. 257 Author's Address 259 Mark R. Crispin 260 Networks and Distributed Computing 261 University of Washington 262 4545 15th Aveneue NE 263 Seattle, WA 98105-4527 265 Phone: (206) 543-5762 267 EMail: MRC@CAC.Washington.EDU