idnits 2.17.1 draft-crispin-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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 73: '...onnected clients MUST use exactly this...' RFC 2119 keyword, line 221: '...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 (August 1999) is 9014 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 206 looks like a reference Summary: 9 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 draft-crispin-imapext-thread-00.txt August 1999 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 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 A revised version of this draft document will be submitted to the RFC 29 editor as a Proposed Standard for the Internet Community. 31 Discussion and suggestions for improvement are requested, and should 32 be sent to ietf-imapext@IMC.ORG. This document will expire before 5 33 February 2000. Distribution of this memo is unlimited. 35 Abstract 37 This document describes the server-based threading extension to the 38 IMAP4rev1 protocol. This extension provides substantial performance 39 improvements for IMAP clients which offer threaded views. 41 A server which supports this extension indicates this with more or 42 more capability names consisting of "THREAD-" followed by a supported 43 threading algorithm name as described in this document. This 44 provides for future upwards-compatible extensions. 46 Extracted Subject Text 48 Threading algorithms use a version of the subject which has specific 49 subject artifacts of deployed Internet mail software removed. Due to 50 the complexity of these artifacts, the above syntax is ambiguous. 51 The following procedure is followed to determing the actual "base 52 subject": 54 (1) Remove all trailing text of the subject that matches 55 the subj-trailer ABNF, repeat until no more matches are 56 possible. 58 (2) Remove all prefix text of the subject that matches 59 subj-leader. 61 (3) If there is prefix text of the subject that matches 62 subj-blob, and removing that prefix leaves a non-empty 63 subj-base, then remove the prefix text. 65 (4) Repeat (2) and (3) until no matches remain. 67 (5) Convert any RFC 2047 encoded-words in the remaining 68 subj-base to UTF-8. 70 (6) The resulting text is the "base subject" used in the 71 THREAD. 73 All servers and disconnected clients MUST use exactly this algorithm 74 when threading. Otherwise there is potential for a user to get 75 inconsistant results based on whether they are running in connected 76 or disconnected IMAP mode. 78 Additional Commands 80 This command is an extension to the IMAP4rev1 base protocol. 82 The section header is intended to correspond with where it would be 83 located in the main document if it was part of the base 84 specification. 86 6.3.THREAD. THREAD Command 88 Arguments: threading algorithm 89 charset specification 90 searching criteria (one or more) 92 Data: untagged responses: THREAD 94 Result: OK - thread completed 95 NO - thread error: can't thread that charset or 96 criteria 97 BAD - command unknown or arguments invalid 99 The THREAD command is a variant of SEARCH with threading semantics 100 for the results. Thread has two arguments before the searching 101 criteria argument; a threading algorithm, and the searching 102 charset. Note that unlike SEARCH, the searching charset argument 103 is mandatory. 105 There is also a UID THREAD command which corresponds to THREAD the 106 way that UID SEARCH corresponds to SEARCH. 108 The THREAD command first searches the mailbox for messages that 109 match the given searching criteria using the charset argument for 110 the interpretation of strings in the searching criteria. It then 111 returns the matching messages in an untagged THREAD response, 112 threaded according to the specified threading algorithm. Unlike 113 SEARCH, if no messages match the searching criteria in a THREAD 114 command, no untagged THREAD response is returned. 116 The defined threading algorithms are as follows: 118 ORDEREDSUBJECT 119 The ORDEREDSUBJECT threading algorithm is also referred to as 120 "poor man's threading." The searched messages are sorted by 121 subject and then by sent date, equivalent to a "SORT (SUBJECT 122 DATE)". The messages are then split into separate threads, 123 with each thread containing messages with the same extracted 124 subject text. Finally, the threads are sorted by the sent date 125 of the first message in the thread. 127 Example: C: A283 THREAD ORDEREDSUBJECT UTF-8 SINCE 5-AUG-1999 128 S: * THREAD (146 151)(144 145)(155)(147 148 152 129 167)(182)(181)(149)(154)(153)(164 170)(156) 130 (158 161 162)(157 160 163)(159)(183 185)(165) 131 (166)(168)(169)(171)(172)(173)(186)(174)(150) 132 (175)(176)(177 179 184)(178)(180)(187) 133 S: A283 OK THREAD completed 134 C: A284 THREAD ORDEREDSUBJECT US-ASCII TEXT "gewp" 135 S: A284 OK THREAD completed 137 Note: The line breaks in the first client response are for 138 editorial clarity and do not appear in a real THREAD 139 response. 141 Additional Responses 143 This response is an extension to the IMAP4rev1 base protocol. 145 The section heading of this response is intended to correspond with 146 where it would be located in the main document. 148 7.2.THREAD. THREAD Response 150 Data: one or more threads 152 The THREAD response occurs as a result of a THREAD or UID THREAD 153 command. It contains one or more threads. A thread consists of a 154 parenthesized list of thread members. Thread members consist of 155 one or more message numbers until the thread splits into multiple 156 sub-threads, at which point the thread nests into multiple sub- 157 threads. There is no limit to the nesting of threads. 159 The messages numbers refer to those messages that match the search 160 criteria. For THREAD, these are message sequence numbers; for UID 161 THREAD, these are unique identifiers. 163 Example: S: * THREAD (2)(3 6 (4 23)(44 7 96)) 165 In this example, there are two threads. The first thread 166 consists only of message 2. The second thread consists 167 of the messages 3 and 6, after which it splits into two 168 subthreads; the first of which contains messages 4 and 169 23, and the second of which contains messages 44, 7, and 170 96. 172 2 173 ,- 4 - 23 174 3 - 6 -< 175 `- 44 - 7 - 96 177 Formal Syntax of THREAD commands and Responses 179 thread-data = "THREAD" SPACE 1*thread-list 181 thread-list = "(" thread-members / thread-nested ")" 183 thread-members = nz-number *(SP nz-number) [SP thread-nested] 185 thread-nested = 2*thread-list 187 thread = ["UID" SPACE] "THREAD" SP thread-algorthm 188 SP search-charset 1*(SP search-key) 190 thread-algorithm = "ORDEREDSUBJECT" / atom 192 The following syntax describes subject extraction rules (1)-(5): 194 subject = *(subj-leader / subj-blob) subj-base *subj-trailer 196 subj-repeat = "[" 1*DIGIT "]" 198 subj-refwd = ("re" / ("fw" ["d"])) [subj-repeat] ":" 200 subj-leader = subj-refwd / WSP 202 subj-blob = "[" 1*BLOBCHAR "]" *WSP 204 subj-trailer = "(fwd)" / WSP 206 subj-base = NONWSP *([WSP] NONWSP) 208 BLOBCHAR = %x01-5c / %x5e-7f 209 ; any CHAR except ']' 211 NONWSP = %x01-08 / %x0a-1f / %x21-7f 212 ; any CHAR other than WSP 214 Security Considerations 216 Security issues are not discussed in this memo. 218 Internationalization Considerations 220 By default, strings are threaded according to the "minimum sorting 221 collation algorithm". All implementations of THREAD MUST implement 222 the minimum sorting collation algorithm. 224 In the minimum sorting collation algorithm, the 26 Latin alphabetics 225 are sorted in a case-insensitive fashion; that is, "A" and "a" are 226 treated as exact equals. All other characters are sorted according 227 to their octet values, as expressed in UTF-8. No attempt is made to 228 treat composed characters specially. 230 Other sorting collations, and the ability to change the sorting 231 collation, will be defined in a separate document dealing with IMAP 232 internationalization. 234 It is anticipated that there will be a generic Unicode sorting 235 collation, which will provide generic case-insensitivity for 236 alphabetic scripts, specification of composed character handling, and 237 language-specific sorting collations. A server which implements 238 non-default sorting collations will modify its sorting behavior 239 according to the selected sorting collation. 241 Non-English translations of "Re" or "Fw"/"Fwd" are not specified for 242 removal in the extracted subject text process. By specifying that 243 only the English forms of the prefixes are used, it becomes a simple 244 display time task to localize the prefix language for the user. If, 245 on the other hand, prefixes in multiple languages are permitted, the 246 result is a geometrically complex, and ultimately unimplementable, 247 task. In order to improve the ability to support non-English display 248 in Internet mail clients, only the English form of these prefixes 249 should be transmitted in Internet mail messages. 251 Author's Address 253 Mark R. Crispin 254 Networks and Distributed Computing 255 University of Washington 256 4545 15th Aveneue NE 257 Seattle, WA 98105-4527 259 Phone: (206) 543-5762 261 EMail: MRC@CAC.Washington.EDU