idnits 2.17.1 draft-daboo-imapext-view-02.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'UNSEEN 12' is mentioned on line 573, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 340, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 341, but not defined == Missing Reference: 'UIDVALIDITY 3857429045' is mentioned on line 574, but not defined == Unused Reference: 'MIME-IMB' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'RFC-822' is defined on line 708, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) -- No information found for draft-crispin-imapext-sort - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SORT' -- Possible downref: Normative reference to a draft: ref. 'THREAD' Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAP Extensions Working Group C. Daboo 2 Internet Draft: IMAP VIEW Extension M. Pustilnik 3 M. Crispin 4 Document: draft-daboo-imapext-view-02.txt March 2000 6 IMAP VIEW Extension 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 RFC2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 23 Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Copyright Notice 28 Copyright (C) The Internet Society (2000). All Rights Reserved. 30 Table of Contents 31 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 32 2 Conventions Used in This Document . . . . . . . . . . . . . 2 33 3 Introduction and Overview . . . . . . . . . . . . . . . . . . 2 34 4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 4 35 4.1 VIEW Command . . . . . . . . . . . . . . . . . . . . . . 4 36 4.1.1 VIEW SET . . . . . . . . . . . . . . . . . . . . . . 4 37 4.1.2 VIEW . . . . . . . . . . . . . . . . . 6 38 4.2 Modified SELECT and EXAMINE commands . . . . . . . . . . 7 39 5 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 8 40 5.1 Response Conditions . . . . . . . . . . . . . . . . . . 8 41 5.2 VIEW Untagged Response . . . . . . . . . . . . . . . . . 9 42 5.2.1 New message arrival . . . . . . . . . . . . . . . . 9 43 5.2.2 Messages moving in the view . . . . . . . . . . . . . 10 44 5.2.3 VIEW SEARCH Response . . . . . . . . . . . . . . . . 12 45 5.3 EXISTS Untagged Response . . . . . . . . . . . . . . . . 12 46 5.4 EXPUNGE Untagged Response . . . . . . . . . . . . . . . 12 47 6 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 48 7 Security Considerations . . . . . . . . . . . . . . . . . . 14 49 8 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 50 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 51 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 53 1 Abstract 55 The VIEW extension to the Internet Message Access Protocol [IMAP4] 56 permits a subset of messages in the mailbox to be processed 57 separately from the entire set of messages in the mailbox. This 58 allows a client to restrict its view to only the messages appearing 59 in this set. The subset of messages also need not be returned in 60 order of their sequence numbers, allowing clients to access messages 61 in a particular sort order. 63 The subsetting and sorting of messages is handled by existing 64 [IMAP4] commands that return a set of messages as their result. 65 This extension takes the set returned from such a command and 66 applies the VIEW methodology to it. 68 2 Conventions Used in This Document 70 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 71 NOT", and "MAY" in this document are to be interpreted as described 72 in "Key words for use in RFCs to Indicate Requirement Levels" 73 [KEYWORDS]. 75 Formal syntax is defined using ABNF [ABNF]. 77 In examples, "C:" and "S:" indicate lines sent by the client and 78 server respectively. 80 3 Introduction and Overview 82 The VIEW extension is present in any IMAP4 implementation which 83 returns "VIEW" as one of the supported capabilities in the 84 CAPABILITY command. 86 The VIEW extension specifies one new command and introduces one new 87 untagged response, modifies two existing [IMAP4] commands and two 88 existing [IMAP4] untagged responses, as well as putting requirements 89 on standard IMAP4 protocol responses when the command is in effect. 91 This document also specifies how the VIEW extension works when the 92 IMAP4 IDLE [IDLE] extension is present on a server. However, the 93 VIEW extension does not require the IDLE extension to be present on 94 the server. 96 Each of the features in VIEW are optimizations; clients can provide 97 the same functionality, albeit more slowly, by using existing 98 commands. 100 The design goal of the VIEW extension is to allow clients to 101 reference messages only by their "view position numbers" as opposed 102 to sequence numbers or UIDs, if so desired, and thus remove the need 103 for the client to maintain its own mapping between sequence number, 104 UID and view position. 106 This extension makes the following changes to the IMAP4 protocol: 108 (a) Adds a new VIEW command which takes one of two forms: 110 (i) The first form, VIEW SET, takes an optional sub-command and 111 is used to initiate or cancel the view mechanism on the server. 113 (ii) In the second form, the VIEW command is used with a FETCH, 114 COPY, STORE, SEARCH, NOOP [IMAP4] or IDLE [IDLE] command, and 115 instructs the server to interpret the sequence numbers provided 116 by the client in the command as VIEW positions (as described 117 below), or to return results using view positions rather than 118 sequence numbers, or to do a complete update of the view. The 119 VIEW COPY command also requires that messages be copied in view 120 order into the destination mailbox. The VIEW IDLE command is 121 only available when the server also supports the IDLE [IDLE] 122 extension. 124 (b) Allows the arguments of the VIEW SET command to appear as 125 arguments of the SELECT or EXAMINE commands [IMAP4] to allow 126 selecting a mailbox and setting a view in a single round-trip. 128 When the VIEW SET command is used by the client, the following 129 changes also take place: 131 (c) New FETCH message data response item: 133 VIEW 134 Indicates the position of messages in the view, which may be 135 different from message sequence number. 137 (d) New untagged response: 139 VIEW 140 Indicates new message arrival, a change in position of a 141 message within the current view or a message moving in or 142 out of the current view. The sequence number, UID and new 143 view position number of the message are supplied, and 144 optionally the old position when the message is not new. 145 Can also be used to return SEARCH results using view 146 position numbers rather than sequence numbers or UIDs. 148 (e) Changes to untagged responses and response codes: 150 EXISTS 151 The standard EXISTS response is enhanced to include 152 information about the total number of messages in the 153 current view. 155 EXPUNGE 156 The standard EXPUNGE response is enhanced to include 157 information about message UID and view position. 159 The rest of this document describes these changes more rigorously. 160 The document will use the IMAP4 SEARCH command as an example of a 161 sub-command to VIEW SET. However, other commands can be used with 162 VIEW SET as well. 164 4 Commands 166 4.1 VIEW Command 168 The VIEW command takes one of two forms. 170 4.1.1 VIEW SET 172 Arguments: OPTIONAL sub-command and associated arguments: 173 this draft currently only allows the SEARCH command 174 as the sub-command, however, anticipated SORT [SORT] 175 and THREAD [THREAD] commands are expected to be 176 added to this. 178 Responses: REQUIRED untagged responses: modified EXISTS if 179 sub-command present 181 Result: OK - view completed, now in view state 182 NO - view failure 183 BAD - command unknown or arguments invalid 185 The VIEW SET command is only available when the server is in 186 'selected state' [IMAP4]. Thus a successful SELECT or EXAMINE 187 command MUST have been issued before VIEW SET can be used. If a 188 client attempts to use VIEW SET while the server is not in 'selected 189 state', then the server MUST respond with a BAD response. Note that 190 a view can also be initiated during a SELECT or EXAMINE command, as 191 described in Section 4.2. 193 When the VIEW SET command is in effect (either by an explicit VIEW 194 SET command or by a modified SELECT or EXAMINE command), it results 195 in the following changes to the IMAP4 protocol: 197 (a) The server creates a 'view' that is a subset of messages in the 198 mailbox that match the results of the sub-command. The position 199 of a message in the view, its view position number, is then 200 given by the VIEW fetch item response. Messages outside of the 201 view have a view position of 0 (zero). 203 (b) The VIEW command can be used by the client to request 204 information about messages in the current view set, without 205 requiring the client to determine the view positions of every 206 message in the mailbox (see Section 4.1.2). 208 (c) The server MUST return a VIEW fetch item in every FETCH 209 response, including unsolicted FETCH responses. This ensures 210 the client does not need to maintain its own mapping from 211 sequence numbers to view positions. 213 (d) A new VIEW untagged response MUST be sent by the server when 214 changes are made to the view by the arrival of new messages, the 215 removal of messages, and the change in status of messages. The 216 rules governing when these responses are issued are described in 217 more detail in Section 5.1. 219 (e) The server MUST modify the EXISTS untagged response (see Section 220 5.3) to include additional information to indicate the current 221 number of messages in the view set. 223 (f) The server MUST modify the EXPUNGE untagged response (see 224 Section 5.4) to include additional information to indicate the 225 expunged message's UID and view position number. 227 (g) The VIEW SET command with no sub-command can be used to turn off 228 the view facility and return the server to standard IMAP4 229 behaviour. 231 (h) A VIEW SET command with a sub-command (see Section 4.1.2) can be 232 used while another VIEW SET is in effect. This results in the 233 view being 'reset' to use the new VIEW SET parameters. 235 (i) Any SELECT, EXAMINE or CLOSE command issued while a VIEW SET is 236 in effect has the behaviour of cancelling the current view 237 behaviour and returns the server to standard [IMAP4] behaviour, 238 unless the SELECT or EXAMINE commands include a new VIEW SET 239 arguments as described in Section 4.2. 241 Examples: 242 C: A999 VIEW SET SEARCH FROM "Smith" 243 S: * 23 EXISTS 5 244 S: A999 OK VIEW SET completed 246 4.1.2 VIEW 248 Arguments: command name 249 command arguments 251 Responses: untagged responses: FETCH, VIEW SEARCH, VIEW 252 responses appropriate for 253 NOOP and IDLE commands 255 Result: OK - VIEW command completed 256 NO - VIEW command error 257 BAD - command unknown or arguments invalid 259 This version of the VIEW command is only available when the VIEW SET 260 command is in effect. Clients MUST NOT issue this version of the 261 VIEW command when a VIEW SET is not in effect, and servers MUST 262 respond with a tagged BAD response if it receives a VIEW command of 263 this type when VIEW SET is not in effect. This version of the VIEW 264 command has three forms. 266 In the first form, it takes as its arguments a COPY, FETCH, or STORE 267 command [IMAP4] with arguments appropriate for the associated 268 command. However, the numbers in the message set argument are view 269 position numbers instead of message sequence numbers. 271 When the VIEW COPY form is used, the server MUST copy messages into 272 the destination mailbox in the order they appear in the current 273 view. This may be different from the ordering of the view position 274 numbers provided as the argument to the VIEW COPY command. 276 In the second form, the VIEW command takes a SEARCH command with 277 SEARCH command arguments [IMAP4]. The interpretation of the 278 arguments is the same as with SEARCH [IMAP4]; however, the numbers 279 returned in a VIEW SEARCH response (see Section 5.2.3) for a VIEW 280 SEARCH command are view position numbers instead of message sequence 281 numbers. In addition, the search is carried out only on those 282 messages in the current view set, so a view position of 0 (zero) 283 MUST NOT be returned in the search results. 285 In the third form, the VIEW command takes a NOOP [IMAP4] or an IDLE 286 [IDLE] command as its argument. The use of these commands, as 287 opposed to their unmodified alternatives of NOOP and IDLE, allows 288 the server to inform the client of changes to the view that it is 289 normally not allowed to do. This is described in more detail in 290 Section 5.1. 292 When a FETCH response [IMAP4] is returned by the server when the 293 VIEW SET command is in effect, the number after the "*" in an 294 untagged FETCH response is always a message sequence number, not a 295 view position number, even for a response to any of the above VIEW 296 commands. However, server implementations MUST implicitly include 297 the VIEW fetch item as part of any FETCH response caused by a VIEW 298 command, regardless of whether a VIEW was specified as a message 299 data item to any FETCH, as described in Section 4.1.1 (c). 301 Examples: 302 C: A999 VIEW FETCH 1:3 FLAGS 303 S: * 23 FETCH (FLAGS (\Seen) VIEW 2) 304 S: * 24 FETCH (FLAGS (\Seen) VIEW 3) 305 S: * 25 FETCH (FLAGS (\Seen) VIEW 1) 306 S: A999 OK VIEW FETCH completed 308 C: A999 VIEW SEARCH UNSEEN 309 S: * VIEW SEARCH 1 2 4 6 310 S: A999 OK VIEW SEARCH completed 312 4.2 Modified SELECT and EXAMINE commands 314 This extension modifies the syntax of the existing IMAP4 SELECT and 315 EXAMINE commands as follows. 317 Arguments: mailbox name 318 OPTIONAL view set arguments 320 Response: same as [IMAP4] except for modified EXISTS 322 Result: same as [IMAP4] 324 The IMAP4 SELECT and EXAMINE commands are modified to include 325 optional VIEW SET command arguments after the mailbox name. This 326 allows a client to select a mailbox and set a view in a single 327 command. The syntax for the optional arguments are the same as for 328 the VIEW SET command arguments. 330 When the optional VIEW SET command arguments are present, the EXISTS 331 response that is normally sent by the server as part of the SELECT 332 or EXAMINE command response is modified to include the current 333 number of messages in the view, as described in Section 4.1.1 (e). 335 Examples: 336 C: A142 SELECT INBOX SEARCH FROM "Smith" 337 S: * 172 EXISTS 5 338 S: * 1 RECENT 339 S: * OK [UNSEEN 12] Message 12 is first unseen 340 S: * OK [UIDVALIDITY 3857529045] UIDs valid 341 S: * OK [UIDNEXT 4392] Predicted next UID 342 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 343 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 344 S: A142 OK [READ-WRITE] SELECT with VIEW SET completed 346 5 Responses 348 5.1 Response Conditions 350 There are a number of conditions that can give rise to changes in 351 the state of a mailbox when a VIEW SET command is in effect: 353 (a) New messages arriving in the mailbox that also match the current 354 view criteria 356 (b) New messages arriving in the mailbox that do not match the 357 current view criteria 359 (c) Messages removed from the mailbox (via EXPUNGE) that also match 360 the current view criteria 362 (d) Messages removed from the mailbox (via EXPUNGE) that do not 363 match the current view criteria 365 (e) Messages that do not match the current view criteria, but whose 366 state changes (e.g. a change in the message FLAGS) such that 367 they now match the current view criteria 369 (f) Messages that match the current view criteria, but whose state 370 changes (e.g. FLAGS) such that they no longer match the current 371 view criteria 373 (g) Messages that match the current view criteria, but whose state 374 changes (e.g. FLAGS) resulting in a change to their view 375 position, whilst still matching the current view criteria 377 When VIEW SET is in effect, a server MUST always send untagged 378 responses for conditions (a), (b), (c), (d) and (e). Changes caused 379 by conditions (f) and (g) MUST NOT be sent unless a VIEW NOOP or 380 VIEW IDLE command is in effect. This behaviour ensures that the 381 'view' presented to the user via their client remains 'static', 382 except for new message arrival and message removal, until a 383 'refresh' of the view is requested via a VIEW NOOP or VIEW IDLE 384 command, or the view is cancelled or reset. Clients that want to 385 present the user with a 'dynamic' view, one that changes when any of 386 the conditions (a) through (g) occur, should either poll the server 387 using VIEW NOOP (as opposed to just NOOP) or use VIEW IDLE (as 388 opposed to just IDLE [IDLE]). 390 Summary of response conditions and resulting untagged responses when 391 the VIEW SET command is in effect: 393 Command in progress untagged response returned for 394 ------------------------ ------------------------------------ 395 any, except NOOP or IDLE (a), (b), (c), (d), (e) 396 VIEW NOOP or VIEW IDLE (a), (b), (c), (d), (e), (f), (g) 398 Response Condition untagged response used 399 ------------------------ ------------------------------------ 400 (a), (b) VIEW (Section 5.2.1) 401 (c), (d) EXPUNGE (Section 5.4) 402 (e), (f), (g) VIEW (Section 5.2.2) 404 5.2 VIEW Untagged Response 406 The VIEW untagged response is used to inform the client of changes 407 to the current view. This includes new messages appearing in the 408 view, messages being removed from the view, and messages changing 409 position inside the view. 411 5.2.1 New message arrival 413 VIEW 415 indicates that a new message has arrived with the given sequence 416 number, UID and view position number 418 When using the VIEW SET command, the VIEW untagged response augments 419 the EXISTS untagged response as a means of new mail notification. 420 Specifically it is used to tell the client where new messages appear 421 in the current view. The server MUST send an untagged VIEW response 422 for every new message that arrives in the mailbox, after the 423 corresponding untagged EXISTS response is sent to indicate this, 424 when the VIEW SET command is in effect. 426 When the VIEW SET command is in effect, and the view position number 427 of a new message is non-zero (i.e. the new message appears in the 428 current view), the untagged VIEW response causes the view position 429 numbers of all subsequent messages in the mailbox's current view to 430 be incremented. This corresponds to response condition (a) 431 described in Section 5.1. 433 Example: 435 C: NOOP 436 S: * 173 EXISTS 24 437 S: * 1 RECENT 438 S: * 173 VIEW 5274234 14 439 S: NOOP complete 441 indicates that a new message with sequence number 173 and UID 442 5274234 has been inserted into the view with view position 443 number 14. Any message that used to have a view position number 444 14 is now at position 15, etc. 446 If a new message arrives outside the current view (i.e. not matching 447 the specified search criteria), the view position number of the new 448 message is given as 0. This corresponds to response condition (b) 449 described in Section 5.1. 451 Example: 453 C: NOOP 454 S: * 174 EXISTS 24 455 S: * 2 RECENT 456 S: * 174 VIEW 5274235 0 457 S: NOOP complete 459 indicates that a message has arrived with sequence number 174 460 and UID 5274235, however, the VIEW SET command in effect 461 prevents it from being in the current view. 463 5.2.2 Messages moving in the view 465 VIEW 467 indicates that a message with the given sequence number and UID 468 has changed its position within the view 470 Some sub-commands of the VIEW SET command may change the sort order 471 of messages in the view. In such a case, changes to message flags 472 or keywords can cause the position of messages in sorted order to 473 change. Also, when search criteria are specified, changes to 474 message flags or keywords can cause messages to move into or outside 475 of the view. The server MUST communicate these changes to the 476 client by sending it the VIEW untagged response, according to the 477 rules of Section 5.1. 479 When VIEW SET search criteria are in effect, changes made to a 480 message can cause it to drop out of view or, on the contrary, become 481 visible. When a message drops out of view, the new view position 482 number is sent as 0. Similarly, when a message appears in view, for 483 example, as a result of another agent changing the message 484 attributes, the old view position number is sent as 0. 486 When the old view position number in the VIEW untagged response is 487 0, the effect of VIEW is a message inserted into the view at the 488 position given by . The view position numbers of all 489 subsequent messages in the current view are implicitly incremented. 490 This corresponds to response condition (e) described in Section 491 5.1. 493 When the new view position number in the VIEW untagged response is 494 0, the effect of VIEW is a message removed from the view at the 495 position given by . The view position numbers of all 496 subsequent messages in the current view are implicitly decremented. 497 This corresponds to response condition (f) described in Section 498 5.1. This untagged response MUST only be sent when a VIEW NOOP or 499 VIEW IDLE command is in effect. 501 When both the and view positions are non-zero, then the 502 view positions of messages between the and positions 503 need to be implicitly decremented or incremented depending on 504 whether the view position is less than or greater than the 505 view position, respectively. This corresponds to response 506 condition (g) described in Section 5.1. This untagged response MUST 507 only be sent when a VIEW NOOP or VIEW IDLE command is in effect. 509 It is meaningless to have a VIEW untagged response where both 510 and view position numbers are 0; the server MUST NOT generate 511 VIEW responses of this form. 513 VIEW untagged responses indicating messages moving in the view MUST 514 NOT be sent as the result of messages being expunged (which is 515 handled by the modified untagged EXPUNGE response), or when no 516 command is in progress, or while responding to a FETCH, SEARCH or 517 STORE command. These rules are necessary to prevent loss of 518 synchronization of message sequence numbers between client and 519 server. 521 Examples: 523 S: * 172 VIEW 5274234 2 14 525 indicates that the view position of the message with sequence 526 number 172 and UID equal to 5274234 has changed from 14 to 2. 527 The view position numbers of the messages in the range 2:13 are 528 incremented. 530 S: * 172 VIEW 5274234 0 14 532 indicates that the message with view position number 14 has 533 dropped out of view. The view position numbers of subsequent 534 messages are decremented. The message continues to exist, 535 however, it is outside of the current view and is therefore no 536 longer accessible to the session via the VIEW command. 538 S: * 173 VIEW 5274234 2 0 540 indicates that the message with UID 5274234 has appeared in the 541 current view and has been assigned view position number 2. The 542 view position numbers of subsequent messages are incremented. 544 5.2.3 VIEW SEARCH Response 546 VIEW SEARCH 548 The VIEW SEARCH response occurs as a result of a VIEW SEARCH 549 command. The view position number(s) refer to those messages that 550 match the search criteria. Each number is delimited by a space. 552 Example: S: * VIEW SEARCH 2 3 6 554 5.3 EXISTS Untagged Response 556 <# in mailbox> EXISTS <# in view> 558 indicates the total number of messages in the mailbox and in the 559 current view 561 The modified EXISTS untagged response MUST only be used when the 562 VIEW SET command is in effect. This MUST be sent in response to a 563 VIEW SET command taking a sub-command argument. Otherwise this 564 response is sent under the same circumstances as the unmodifed 565 EXISTS response (i.e. in when there is a change to the total number 566 of messages in the mailbox). 568 Example: 570 C: A142 SELECT INBOX 571 S: * 172 EXISTS 572 S: * 3 RECENT 573 S: * OK [UNSEEN 12] Message 12 is first unseen 574 S: * OK [UIDVALIDITY 3857429045] UIDs valid 575 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 576 S: OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 577 S: A142 OK [READ-WRITE] SELECT completed 578 C: A143 VIEW SET SEARCH FROM "Smith" 579 S: * 172 EXISTS 23 580 S: A143 OK VIEW SET completed 582 In this example, there are 172 messages in the mailbox and 23 583 messages have a from address including the text "Smith". 585 5.4 EXPUNGE Untagged Response 586 EXPUNGE 588 indicates that a message with given sequence number, UID and 589 view position number has been permanently removed from the 590 mailbox 592 When VIEW SET is in effect, the EXPUNGE untagged response [IMAP4] is 593 modified to include the UID and view position number of the message 594 being expunged. The server MUST use this modified form of the 595 EXPUNGE response whenever a VIEW SET command is in effect. 597 When the view position number of the expunged message is non-zero, 598 the modified EXPUNGE untagged response causes the view position 599 numbers of all subsequent messages in the mailbox's current view to 600 be decremented. This corresponds to response condition (c) 601 described in Section 5.1. 603 When search criteria are specified in the VIEW SET command, and a 604 message outside the current view is expunged, the view position 605 number of the expunged message is given as 0. This corresponds to 606 response condition (d) described in Section 5.1. 608 Examples: 610 S: * 172 EXPUNGE 5274234 14 612 indicates that the message with sequence number 172, UID 5274234 613 and view position number 14 has been expunged from its mailbox. 614 Any message previously at position 15 is now at position 14, etc 616 S: * 173 EXPUNGE 5274234 0 618 indicates that a message with sequence number 173, UID 5274234 619 was expunged, however, the message was outside the current view. 621 A modified EXPUNGE untagged response MUST NOT be sent when no 622 command is in progress; nor while responding to a FETCH, SEARCH or 623 STORE command. This rule is necessary to prevent loss of 624 synchronization of message sequence numbers between client and 625 server. 627 6 Formal Syntax 629 The following syntax specification uses the Augmented Backus-Naur 630 Form (ABNF) notation as specified in [ABNF]. 632 Non-terminals referenced but not defined below are as defined by 633 [IMAP4]. 635 Except as noted otherwise, all alphabetic characters are case- 636 insensitive. The use of upper or lower case characters to define 637 token strings is for editorial clarity only. Implementations MUST 638 accept these strings in a case-insensitive fashion. 640 examine = "EXAMINE" SP mailbox [SP view-set-arg] 641 ; redefines [IMAP4] EXAMINE command 643 exists_resp = number "EXISTS" SP number 644 ; replaces standard [IMAP4] EXISTS response 645 ; when VIEW SET is in effect 647 expunge_resp = nz-number "EXPUNGE" SP uniqueid SP position 648 ; replaces standard IMAP4 EXPUNGE response 649 ; when VIEW SET is in effect 651 msg-att-dynamic =/ "VIEW" SP position 652 ; adds new message data item to IMAP4 653 ; FETCH response 655 position = number ["." number] 656 ; position number of messages in the view 657 ; may be hierarchical if sub-command defines 658 ; hierarchic ordering of messages 659 ; 0 means outside of the current view 661 select = "SELECT" SP mailbox [SP view-set-arg] 662 ; redefines [IMAP4] SELECT command 664 view = "VIEW" SP (view-set / view-reference) 666 view-mailbox-data = "VIEW" SP (("SEARCH" *(SP position)) / OTHER) 667 ; OTHER reserved for future expansion 669 view-msg-data = nz_number SP "VIEW" SP uniqueid 670 SP position [SP position] 672 view-reference = copy / fetch / store / search / "NOOP" / idle 673 ; copy, fetch, store, search defined 674 ; in [IMAP4], idle defined in [IDLE] 676 view-response = view-msg-data / view-mailbox-data 678 view-set = "SET" [SP view-set-arg] 680 view-set-arg = search / sort / thread / OTHER 681 ; search is defined in [IMAP4] 682 ; sort is defined in [SORT] 683 ; thread is defined in [THREAD] 684 ; OTHER reserved for future definition 686 7 Security Considerations 687 There are no known security issues with this extension. 689 8 References 691 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 692 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 693 November 1997. 695 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 696 Requirement Levels", RFC 2119, Harvard University, March 1997. 698 [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, IBM T.J. Watson 699 Research Center, June 1997. 701 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 702 4rev1", RFC 2060, University of Washington, December 1996. 704 [MIME-IMB] Freed, N., and Borenstein, N.., "MIME (Multipurpose 705 Internet Mail Extensions) Part One: Format of Internet Message 706 Bodies", RFC 2045, November 1996. 708 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 709 Text Messages", STD 11, RFC822, August 1982. 711 [SORT] Crispin, M., "Internet Message Access Protocol - SORT 712 Extension", draft-crispin-imapext-sort-01.txt (Work in progress) 714 [THREAD] Crispin, M., "Internet Message Access Protocol - THREAD 715 Extension", draft-crispin-imapext-thread-01.txt (Work in progress) 717 9 Acknowledgments 719 Steve Hole, Chris Newman and Larry Osterman have made significant 720 contributions to the creation and refinement of the ideas expressed 721 in this document. 723 10 Authors' Addresses 725 Cyrus Daboo 726 Cyrusoft International, Inc. 727 Suite 780, 5001 Baum Blvd. 728 Pittsburgh, PA 15213 730 Phone: (412) 605-0499 731 Email: daboo@cyrusoft.com 733 Mark Pustilnik 734 Microsoft 735 1 Microsoft Way 736 Redmond, WA 98052 738 Phone: (425) 703-5758 739 Email: markpu@microsoft.com 741 Mark R. Crispin 742 Networks and Distributed Computing 743 University of Washington 744 4545 15th Aveneue NE 745 Seattle, WA 98105-4527 747 Phone: (206) 543-5762 748 EMail: MRC@CAC.Washington.EDU