idnits 2.17.1 draft-ietf-imapext-sort-13.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 the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([THREADING], [IMAP], [IMAP-I18N], [KEYWORDS], [RFC2822]), 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 96: '...onnected clients MUST use exactly this...' RFC 2119 keyword, line 135: '...nd UTF-8 charsets MUST be implemented....' RFC 2119 keyword, line 240: '...nd UTF-8 charsets MUST be implemented....' RFC 2119 keyword, line 279: '... SHOULD treat descendents of...' RFC 2119 keyword, line 305: '...eading algorithm MUST normalize any ms...' (3 more instances...) 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 (May 2003) is 7624 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? 'IMAP' on line 705 looks like a reference -- Missing reference section? 'KEYWORDS' on line 711 looks like a reference -- Missing reference section? 'THREADING' on line 719 looks like a reference -- Missing reference section? 'RFC 2822' on line 327 looks like a reference -- Missing reference section? 'IMAP-I18N' on line 708 looks like a reference -- Missing reference section? 'ABNF' on line 702 looks like a reference -- Missing reference section? 'RFC-2822' on line 714 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMAP Extensions Working Group M. Crispin 3 INTERNET-DRAFT: IMAP SORT K. Murchison 4 Document: internet-drafts/draft-ietf-imapext-sort-13.txt May 2003 6 INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 A revised version of this document will be submitted to the RFC 30 editor as an Informational Document for the Internet Community. 32 A revised version of this draft document will be submitted to the RFC 33 editor as a Proposed Standard for the Internet Community. Discussion 34 and suggestions for improvement are requested, and should be sent to 35 ietf-imapext@IMC.ORG. This document will expire before 14 November 36 2003. Distribution of this memo is unlimited. 38 Abstract 40 This document describes the base-level server-based sorting and 41 threading extensions to the [IMAP] protocol. These extensions 42 provide substantial performance improvements for IMAP clients which 43 offer sorted and threaded views. 45 A server which supports the base-level SORT extension indicates this 46 with a capability name which starts with "SORT". Future, 47 upwards-compatible extensions to the SORT extension will all start 48 with "SORT", indicating support for this base level. 50 A server which supports the THREAD extension indicates this with one 51 or more capability names consisting of "THREAD=" followed by a 52 supported threading algorithm name as described in this document. 53 This provides for future upwards-compatible extensions. 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 57 be interpreted as described in [KEYWORDS]. 59 Base Subject Text 61 Subject sorting and threading use the "base subject," which has 62 specific subject artifacts of deployed Internet mail software 63 removed. Due to the complexity of these artifacts, the formal syntax 64 for the subject extraction rules is ambiguous. The following 65 procedure is followed to determine the actual "base subject" which is 66 used to sort by subject: 68 (1) Convert any RFC 2047 encoded-words in the subject to 69 UTF-8 as described in "internationalization 70 considerations." Convert all tabs and continuations to 71 space. Convert all multiple spaces to a single space. 73 (2) Remove all trailing text of the subject that matches 74 the subj-trailer ABNF, repeat until no more matches are 75 possible. 77 (3) Remove all prefix text of the subject that matches the 78 subj-leader ABNF. 80 (4) If there is prefix text of the subject that matches the 81 subj-blob ABNF, and removing that prefix leaves a non-empty 82 subj-base, then remove the prefix text. 84 (5) Repeat (3) and (4) until no matches remain. 86 Note: it is possible to defer step (2) until step (6), but this 87 requires checking for subj-trailer in step (4). 89 (6) If the resulting text begins with the subj-fwd-hdr ABNF 90 and ends with the subj-fwd-trl ABNF, remove the 91 subj-fwd-hdr and subj-fwd-trl and repeat from step (2). 93 (7) The resulting text is the "base subject" used in the 94 SORT. 96 All servers and disconnected clients MUST use exactly this algorithm 97 when sorting by subject. Otherwise there is potential for a user to 98 get inconsistent results based on whether they are running in 99 connected or disconnected IMAP mode. 101 Sent Date 103 As used in this document, the term "sent date" refers to the date and 104 time from the Date: header, adjusted by time zone. This differs from 105 date-related criteria in SEARCH, which use just the date and not the 106 time, nor adjusts by time zone. 108 Additional Commands 110 These commands are extension to the IMAP4rev1 base protocol. 112 The section headings are intended to correspond with where they would 113 be located in the main document if they were part of the base 114 specification. 116 6.4.SORT. SORT Command 118 Arguments: sort program 119 charset specification 120 searching criteria (one or more) 122 Data: untagged responses: SORT 124 Result: OK - sort completed 125 NO - sort error: can't sort that charset or 126 criteria 127 BAD - command unknown or arguments invalid 129 The SORT command is a variant of SEARCH with sorting semantics for 130 the results. Sort has two arguments before the searching criteria 131 argument; a parenthesized list of sort criteria, and the searching 132 charset. 134 Note that unlike SEARCH, the searching charset argument is 135 mandatory. The US-ASCII and UTF-8 charsets MUST be implemented. 136 All other charsets are optional. 138 There is also a UID SORT command which corresponds to SORT the way 139 that UID SEARCH corresponds to SEARCH. 141 The SORT command first searches the mailbox for messages that 142 match the given searching criteria using the charset argument for 143 the interpretation of strings in the searching criteria. It then 144 returns the matching messages in an untagged SORT response, sorted 145 according to one or more sort criteria. 147 Sorting is in ascending order. Earlier dates sort before later 148 dates; smaller sizes sort before larger sizes; and strings are 149 sorted according to ascending values established by their 150 collation algorithm (see under "Internationalization 151 Considerations"). 153 If two or more messages exactly match according to the sorting 154 criteria, these messages are sorted according to the order in 155 which they appear in the mailbox. In other words, there is an 156 implicit sort criterion of "sequence number". 158 When multiple sort criteria are specified, the result is sorted in 159 the priority order that the criteria appear. For example, 160 (SUBJECT DATE) will sort messages in order by their base subject 161 text; and for messages with the same base subject text will sort 162 by their sent date. 164 Untagged EXPUNGE responses are not permitted while the server is 165 responding to a SORT command, but are permitted during a UID SORT 166 command. 168 The defined sort criteria are as follows. Refer to the Formal 169 Syntax section for the precise syntactic definitions of the 170 arguments. If the associated RFC-822 header for a particular 171 criterion is absent, it is treated as the empty string. The empty 172 string always collates before non-empty strings. 174 ARRIVAL 175 Internal date and time of the message. This differs from the 176 ON criteria in SEARCH, which uses just the internal date. 178 CC 179 RFC-822 local-part of the first "cc" address. 181 DATE 182 Sent date and time from the Date: header, adjusted by time 183 zone. This differs from the SENTON criteria in SEARCH, which 184 uses just the date and not the time, nor adjusts by time zone. 186 FROM 187 RFC-822 local-part of the first "From" address. 189 REVERSE 190 Followed by another sort criterion, has the effect of that 191 criterion but in reverse (descending) order. 192 Note: REVERSE only reverses a single criterion, and does not 193 affect the implicit "sequence number" sort criterion if all 194 other criteria are identicial. Consequently, a sort of 195 REVERSE SUBJECT is not the same as a reverse ordering of a 196 SUBJECT sort. This can be avoided by use of additional 197 criteria, e.g. SUBJECT DATE vs. REVERSE SUBJECT REVERSE 198 DATE. In general, however, it's better (and faster, if the 199 client has a "reverse current ordering" command) to reverse 200 the results in the client instead of issuing a new SORT. 202 SIZE 203 Size of the message in octets. 205 SUBJECT 206 Base subject text. 208 TO 209 RFC-822 local-part of the first "To" address. 211 Example: C: A282 SORT (SUBJECT) UTF-8 SINCE 1-Feb-1994 212 S: * SORT 2 84 882 213 S: A282 OK SORT completed 214 C: A283 SORT (SUBJECT REVERSE DATE) UTF-8 ALL 215 S: * SORT 5 3 4 1 2 216 S: A283 OK SORT completed 217 C: A284 SORT (SUBJECT) US-ASCII TEXT "not in mailbox" 218 S: * SORT 219 S: A284 OK SORT completed 221 6.4.THREAD. THREAD Command 223 Arguments: threading algorithm 224 charset specification 225 searching criteria (one or more) 227 Data: untagged responses: THREAD 229 Result: OK - thread completed 230 NO - thread error: can't thread that charset or 231 criteria 232 BAD - command unknown or arguments invalid 234 The THREAD command is a variant of SEARCH with threading semantics 235 for the results. Thread has two arguments before the searching 236 criteria argument; a threading algorithm, and the searching 237 charset. 239 Note that unlike SEARCH, the searching charset argument is 240 mandatory. The US-ASCII and UTF-8 charsets MUST be implemented. 241 All other charsets are optional. 243 There is also a UID THREAD command which corresponds to THREAD the 244 way that UID SEARCH corresponds to SEARCH. 246 The THREAD command first searches the mailbox for messages that 247 match the given searching criteria using the charset argument for 248 the interpretation of strings in the searching criteria. It then 249 returns the matching messages in an untagged THREAD response, 250 threaded according to the specified threading algorithm. 252 All collation is in ascending order. Earlier dates collate before 253 later dates and strings are collated according to ascending values 254 established by their collation algorithm (see under 255 "Internationalization Considerations"). 257 The defined threading algorithms are as follows: 259 ORDEREDSUBJECT 260 The ORDEREDSUBJECT threading algorithm is also referred to as 261 "poor man's threading." The searched messages are sorted by 262 base subject and then by the sent date. The messages are then 263 split into separate threads, with each thread containing 264 messages with the same base subject text. Finally, the threads 265 are sorted by the sent date of the first message in the thread. 267 The first message of each thread are siblings of each other 268 (the "root"). The second message of a thread is the child of 269 the first message, and subsequent messages of the thread are 270 siblings of the second message and hence children of the 271 message at the root. Hence, there are no grandchildren in 272 ORDEREDSUBJECT threading. 274 Note: earlier versions of this specification specified 275 that each message in an ORDEREDSUBJECT thread is a child 276 (as opposed to a sibling) of the previous message. This 277 is now deprecated. For compatibility with servers which 278 may still use the old definition, client implementations 279 SHOULD treat descendents of a child as being siblings of 280 that child. 282 This is because the old definition mistakenly indicated 283 that there was a parent/child relationship between 284 successive messages in a thread; when in fact there was 285 only a chronological relationship. In clients which 286 indicate parent/child relationships in a thread tree, 287 this would indicate levels of descent which did not 288 exist. 290 REFERENCES 291 The REFERENCES threading algorithm is based on the [THREADING] 292 algorithm written used in "Netscape Mail and News" versions 2.0 293 through 3.0. This algorithm threads the searched messages by 294 grouping them together in parent/child relationships based on 295 which messages are replies to others. The parent/child 296 relationships are built using two methods: reconstructing a 297 message's ancestry using the references contained within it; 298 and checking the original (not base) subject of a message to 299 see if it is a reply to (or forward of) another message. 301 Note: "Message ID" in the following description refers to a 302 normalized form of the msg-id in [RFC 2822]. The actual 303 text in an RFC 2822 may use quoting, resulting in multiple 304 ways of expressing the same Message ID. Implementations of 305 the REFERENCES threading algorithm MUST normalize any msg-id 306 in order to avoid false non-matches due to differences in 307 quoting. 309 For example, the msg-id 310 <"01KF8JCEOCBS0045PS"@xxx.yyy.com> 311 and the msg-id 312 <01KF8JCEOCBS0045PS@xxx.yyy.com> 313 MUST be interpreted as being the same Message ID. 315 The references used for reconstructing a message's ancestry are 316 found using the following rules: 318 If a message contains a References header line, then use the 319 Message IDs in the References header line as the references. 321 If a message does not contain a References header line, or 322 the References header line does not contain any valid 323 Message IDs, then use the first (if any) valid Message ID 324 found in the In-Reply-To header line as the only reference 325 (parent) for this message. 327 Note: Although [RFC 2822] permits multiple Message IDs in 328 the In-Reply-To header, in actual practice this 329 discipline has not been followed. For example, 330 In-Reply-To headers have been observed with email 331 addresses after the Message ID, and there are no good 332 heuristics for software to determine the difference. 333 This is not a problem with the References header however. 335 If a message does not contain an In-Reply-To header line, or 336 the In-Reply-To header line does not contain a valid Message 337 ID, then the message does not have any references (NIL). 339 A message is considered to be a reply or forward if the base 340 subject extraction rules, applied to the original subject, 341 remove any of the following: a subj-refwd, a "(fwd)" 342 subj-trailer, or a subj-fwd-hdr and subj-fwd-trl. 344 The REFERENCES algorithm is significantly more complex than 345 ORDEREDSUBJECT and consists of six main steps. These steps are 346 outlined in detail below. 348 (1) For each searched message: 350 (A) Using the Message IDs in the message's references, link 351 the corresponding messages (those whose Message-ID header 352 line contains the given reference Message ID) together as 353 parent/child. Make the first reference the parent of the 354 second (and the second a child of the first), the second the 355 parent of the third (and the third a child of the second), 356 etc. The following rules govern the creation of these 357 links: 359 If a message does not contain a Message-ID header line, 360 or the Message-ID header line does not contain a valid 361 Message ID, then assign a unique Message ID to this 362 message. 364 If two or more messages have the same Message ID, then 365 only use that Message ID in the first (lowest sequence 366 number) message, and assign a unique Message ID to each 367 of the subsequent messages with a duplicate of that 368 Message ID. 370 If no message can be found with a given Message ID, 371 create a dummy message with this ID. Use this dummy 372 message for all subsequent references to this ID. 374 If a message already has a parent, don't change the 375 existing link. This is done because the References 376 header line may have been truncated by a MUA. As a 377 result, there is no guarantee that the messages 378 corresponding to adjacent Message IDs in the References 379 header line are parent and child. 381 Do not create a parent/child link if creating that link 382 would introduce a loop. For example, before making 383 message A the parent of B, make sure that A is not a 384 descendent of B. 386 Note: Message ID comparisons are case-sensitive. 388 (B) Create a parent/child link between the last reference 389 (or NIL if there are no references) and the current message. 390 If the current message already has a parent, it is probably 391 the result of a truncated References header line, so break 392 the current parent/child link before creating the new 393 correct one. As in step 1.A, do not create the parent/child 394 link if creating that link would introduce a loop. Note 395 that if this message has no references, that it will now 396 have no parent. 398 Note: The parent/child links created in steps 1.A and 1.B 399 MUST be kept consistent with one another at ALL times. 401 (2) Gather together all of the messages that have no parents 402 and make them all children (siblings of one another) of a dummy 403 parent (the "root"). These messages constitute the first 404 (head) message of the threads created thus far. 406 (3) Prune dummy messages from the thread tree. Traverse each 407 thread under the root, and for each message: 409 If it is a dummy message with NO children, delete it. 411 If it is a dummy message with children, delete it, but 412 promote its children to the current level. In other words, 413 splice them in with the dummy's siblings. 415 Do not promote the children if doing so would make them 416 children of the root, unless there is only one child. 418 (4) Sort the messages under the root (top-level siblings only) 419 by sent date. In the case of an exact match on sent date or if 420 either of the Date: headers used in a comparison can not be 421 parsed, use the order in which the messages appear in the 422 mailbox (that is, by sequence number) to determine the order. 423 In the case of a dummy message, sort its children by sent date 424 and then use the first child for the top-level sort. 426 (5) Gather together messages under the root that have the same 427 base subject text. 429 (A) Create a table for associating base subjects with 430 messages, called the subject table. 432 (B) Populate the subject table with one message per each 433 base subject. For each child of the root: 435 (i) Find the subject of this thread, by using the base 436 subject from either the current message or its first 437 child if the current message is a dummy. This is the 438 thread subject. 440 (ii) If the thread subject is empty, skip this message. 442 (iii) Look up the message associated with the thread 443 subject in the subject table. 445 (iv) If there is no message in the subject table with the 446 thread subject, add the current message and the thread 447 subject to the subject table. 449 Otherwise, if the message in the subject table is not a 450 dummy, AND either of the following criteria are true: 452 The current message is a dummy, OR 454 The message in the subject table is a reply or forward 455 and the current message is not. 457 then replace the message in the subject table with the 458 current message. 460 (C) Merge threads with the same thread subject. For each 461 child of the root: 463 (i) Find the message's thread subject as in step 5.B.i 464 above. 466 (ii) If the thread subject is empty, skip this message. 468 (iii) Lookup the message associated with this thread 469 subject in the subject table. 471 (iv) If the message in the subject table is the current 472 message, skip this message. 474 Otherwise, merge the current message with the one in the 475 subject table using the following rules: 477 If both messages are dummies, append the current 478 message's children to the children of the message in 479 the subject table (the children of both messages 480 become siblings), and then delete the current message. 482 If the message in the subject table is a dummy and the 483 current message is not, make the current message a 484 child of the message in the subject table (a sibling 485 of its children). 487 If the current message is a reply or forward and the 488 message in the subject table is not, make the current 489 message a child of the message in the subject table (a 490 sibling of its children). 492 Otherwise, create a new dummy message and make both 493 the current message and the message in the subject 494 table children of the dummy. Then replace the message 495 in the subject table with the dummy message. 497 Note: Subject comparisons are case-insensitive, as 498 described under "Internationalization 499 Considerations." 501 (6) Traverse the messages under the root and sort each set of 502 siblings by sent date. Traverse the messages in such a way 503 that the "youngest" set of siblings are sorted first, and the 504 "oldest" set of siblings are sorted last (grandchildren are 505 sorted before children, etc). In the case of an exact match on 506 sent date or if either of the Date: headers used in a 507 comparison can not be parsed, use the order in which the 508 messages appear in the mailbox (that is, by sequence number) to 509 determine the order. In the case of a dummy message (which can 510 only occur with top-level siblings), use its first child for 511 sorting. 513 Example: C: A283 THREAD ORDEREDSUBJECT UTF-8 SINCE 5-MAR-2000 514 S: * THREAD (166)(167)(168)(169)(172)(170)(171) 515 (173)(174 (175)(176)(178)(181)(180))(179)(177 516 (183)(182)(188)(184)(185)(186)(187)(189))(190) 517 (191)(192)(193)(194 195)(196 (197)(198))(199) 518 (200 202)(201)(203)(204)(205)(206 207)(208) 519 S: A283 OK THREAD completed 520 C: A284 THREAD ORDEREDSUBJECT US-ASCII TEXT "gewp" 521 S: * THREAD 522 S: A284 OK THREAD completed 523 C: A285 THREAD REFERENCES UTF-8 SINCE 5-MAR-2000 524 S: * THREAD (166)(167)(168)(169)(172)((170)(179)) 525 (171)(173)((174)(175)(176)(178)(181)(180)) 526 ((177)(183)(182)(188 (184)(189))(185 186)(187)) 527 (190)(191)(192)(193)((194)(195 196))(197 198) 528 (199)(200 202)(201)(203)(204)(205 206 207)(208) 529 S: A285 OK THREAD completed 531 Note: The line breaks in the first and third client 532 responses are for editorial clarity and do not appear in 533 real THREAD responses. 535 Additional Responses 537 These responses are extensions to the IMAP4rev1 base protocol. 539 The section headings of these responses are intended to correspond 540 with where they would be located in the main document. 542 7.2.SORT. SORT Response 544 Data: zero or more numbers 546 The SORT response occurs as a result of a SORT or UID SORT 547 command. The number(s) refer to those messages that match the 548 search criteria. For SORT, these are message sequence numbers; 549 for UID SORT, these are unique identifiers. Each number is 550 delimited by a space. 552 Example: S: * SORT 2 3 6 554 7.2.THREAD. THREAD Response 556 Data: zero or more threads 558 The THREAD response occurs as a result of a THREAD or UID THREAD 559 command. It contains zero or more threads. A thread consists of 560 a parenthesized list of thread members. 562 Thread members consist of zero or more message numbers, delimited 563 by spaces, indicating successive parent and child. This continues 564 until the thread splits into multiple sub-threads, at which point 565 the thread nests into multiple sub-threads with the first member 566 of each subthread being siblings at this level. There is no limit 567 to the nesting of threads. 569 The messages numbers refer to those messages that match the search 570 criteria. For THREAD, these are message sequence numbers; for UID 571 THREAD, these are unique identifiers. 573 Example: S: * THREAD (2)(3 6 (4 23)(44 7 96)) 575 The first thread consists only of message 2. The second thread 576 consists of the messages 3 (parent) and 6 (child), after which it 577 splits into two subthreads; the first of which contains messages 4 578 (child of 6, sibling of 44) and 23 (child of 4), and the second of 579 which contains messages 44 (child of 6, sibling of 4), 7 (child of 580 44), and 96 (child of 7). Since some later messages are parents 581 of earlier messages, the messages were probably moved from some 582 other mailbox at different times. 584 -- 2 586 -- 3 587 \-- 6 588 |-- 4 589 | \-- 23 590 | 591 \-- 44 592 \-- 7 593 \-- 96 595 Example: S: * THREAD ((3)(5)) 597 In this example, 3 and 5 are siblings of a parent which does not 598 match the search criteria (and/or does not exist in the mailbox); 599 however they are members of the same thread. 601 Formal Syntax of SORT and THREAD commands and Responses 603 sort = ["UID" SP] "SORT" SP 604 "(" sort-criterion *(SP sort-criterion) ")" 605 SP charset 1*(SP search-key) 607 sort-criterion = ["REVERSE" SP] sort-key 609 sort-key = "ARRIVAL" / "CC" / "DATE" / "FROM" / "SIZE" / 610 "SUBJECT" / "TO" 611 thread = ["UID" SP] "THREAD" SP thread-algorithm 612 SP charset 1*(SP search-key) 614 thread-algorithm = "ORDEREDSUBJECT" / "REFERENCES" / atom 616 charset = astring 617 ; CHARSET argument to MUST be registered with IANA 619 sort-data = "SORT" *(SP nz-number) 621 thread-data = "THREAD" [SP 1*thread-list] 623 thread-list = "(" thread-members / thread-nested ")" 625 thread-members = nz-number *(SP nz-number) [SP thread-nested] 627 thread-nested = 2*thread-list 629 The following syntax describes base subject extraction rules (2)-(6): 631 subject = *subj-leader [subj-middle] *subj-trailer 633 subj-refwd = ("re" / ("fw" ["d"])) *WSP [subj-blob] ":" 635 subj-blob = "[" *BLOBCHAR "]" *WSP 637 subj-fwd = subj-fwd-hdr subject subj-fwd-trl 639 subj-fwd-hdr = "[fwd:" 641 subj-fwd-trl = "]" 643 subj-leader = (*subj-blob subj-refwd) / WSP 644 subj-middle = *subj-blob (subj-base / subj-fwd) 645 ; last subj-blob is subj-base if subj-base would 646 ; otherwise be empty 648 subj-trailer = "(fwd)" / WSP 650 subj-base = NONWSP *([*WSP] NONWSP) 651 ; can be a subj-blob 653 BLOBCHAR = %x01-5a / %x5c / %x5e-7f 654 ; any CHAR except '[' and ']' 656 NONWSP = %x01-08 / %x0a-1f / %x21-7f 657 ; any CHAR other than WSP 659 Security Considerations 661 The SORT and THREAD extensions do not raise any security 662 considerations that are not present in the base [IMAP] protocol, and 663 these issues are discussed in [IMAP]. Nevertheless, it is important 664 to remember that IMAP4rev1 protocol transactions, including 665 electronic mail data, are sent in the clear over the network unless 666 protection from snooping is negotiated, either by the use of 667 STARTTLS, privacy protection is negotiated in the AUTHENTICATE 668 command, or some other protection mechanism is in effect. 670 Internationalization Considerations 672 Strings in charsets other than US-ASCII and UTF-8 must be converted 673 to UTF-8 prior to any comparisons. String comparisons used in SORT 674 and THREAD collations are performed as described in [IMAP-I18N]. 676 Non-English translations of "Re" or "Fw"/"Fwd" are not specified for 677 removal in the base subject extraction process. By specifying that 678 only the English forms of the prefixes are used, it becomes a simple 679 display time task to localize the prefix language for the user. If, 680 on the other hand, prefixes in multiple languages are permitted, the 681 result is a geometrically complex, and ultimately unimplementable, 682 task. In order to improve the ability to support non-English display 683 in Internet mail clients, only the English form of these prefixes 684 should be transmitted in Internet mail messages. 686 12. IANA Considerations 688 IMAP4 capabilities are registered by publishing a standards track or 689 IESG approved experimental RFC. The registry is currently located 690 at: 692 http://www.iana.org/assignments/imap4-capabilities 694 This document consitutes registration of the SORT and THREAD IMAP 695 capabilities, as well as the ORDEREDSUBJECT and REFERENCES IMAP 696 threading algorithms. 698 A. References 700 The following documents are normative to this document: 702 [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax 703 Specifications: ABNF", RFC 2234, November 1997. 705 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 706 4rev1", RFC 3501, March 2003. 708 [IMAP-I18N] Newman, C. "Internet Message Access Protocol 709 Internationalization", Work in Progress. 711 [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate 712 Requirement Levels", RFC 2119, Harvard University, March 1997. 714 [RFC-2822] Resnick, P. "Internet Message Format", RFC 2822, April 715 2001. 717 The following documents are informative to this document: 719 [THREADING] Zawinski, J. "message threading", 720 http://www.jwz.org/doc/threading.html, 1997-2002. 722 Author's Address 724 Mark R. Crispin 725 Networks and Distributed Computing 726 University of Washington 727 4545 15th Avenue NE 728 Seattle, WA 98105-4527 730 Phone: (206) 543-5762 731 EMail: MRC@CAC.Washington.EDU 733 Kenneth Murchison 734 Oceana Matrix Ltd. 735 21 Princeton Place 736 Orchard Park, NY 14127 738 Phone: (716) 662-8973 x26 740 EMail: ken@oceana.com