idnits 2.17.1 draft-ietf-lemonade-imap-notify-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 892. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 60 lines == 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 8, 2008) is 5922 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: 'NOTIFICATIONOVERFLOW' is mentioned on line 226, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4551 (Obsoleted by RFC 7162) == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-12 == Outdated reference: A later version (-07) exists of draft-ietf-lemonade-msgevent-03 == Outdated reference: A later version (-05) exists of draft-cridland-imap-context-03 == Outdated reference: A later version (-06) exists of draft-ietf-lemonade-reconnect-client-05 == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-09 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Curtis King 3 Internet-Draft Alexey Melnikov 4 Intended Status: Proposed Standard Isode Ltd. 5 Arnt Gulbrandsen 6 Oryx Mail Systems GmbH 7 February 8, 2008 9 The IMAP NOTIFY Extension 10 draft-ietf-lemonade-imap-notify-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 31 Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft expires in July 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines an IMAP extension which allows a client to 43 request specific kinds of unsolicited notifications for specified 44 mailboxes, such as messages being added to or deleted from 45 mailboxes. 47 Internet-draft February 2008 49 [[Add Updates: RFC-CONTEXT to the headers]] 51 1. Conventions Used in This Document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Formal syntax is defined by [RFC4234] as extended by [RFC3501] and 58 [RFC4466]. 60 The acronym MSN stands for Message Sequence Numbers (see Section 61 2.3.1.2 of [RFC3501]). 63 Example lines prefaced by "C:" are sent by the client and ones 64 prefaced by "S:" by the server. "[...]" means elision. 66 2. Overview and rationale 68 The IDLE command (defined in [RFC2177]) provides a way for the 69 client to go into a mode where the IMAP server pushes notifications 70 about IMAP mailstore events for the selected mailbox. However, the 71 IDLE extension doesn't restrict or control which server events can 72 be sent, or what information the server sends in response to each 73 event. Also, IDLE only applies to the selected mailbox, thus 74 requiring an additional TCP connection per mailbox. 76 This document defines an IMAP extension that allows clients to 77 express their preferences about unsolicited events generated by the 78 server. The extension allows clients to only receive events they 79 are interested in, while servers know that they don't need to go 80 into effort of generating certain types of untagged responses. 82 Without the NOTIFY command defined in this document, and IMAP server 83 will only send information about mailstore changes to the client in 84 the following cases: 85 - as the result of a client command (e.g. FETCH responses to 86 a FETCH or STORE command), 87 - unsolicited responses sent just before the end of a command 88 (e.g. EXISTS or EXPUNGE) as the result of changes in other 89 sessions, and 90 - during an IDLE command. 92 The NOTIFY command extends what information may be returned in those 93 last two cases, and also permits and requires the server to send 94 information about updates between command. The NOTIFY command also 96 Internet-draft February 2008 98 allows for the client to extend what information is sent unsolicited 99 about the selected mailbox, and to request some update information 100 to be sent regarding other mailboxes. 102 For the new messages delivered to or appended to the selected 103 mailbox, the NOTIFY command can be used to request that a set of 104 attributes be sent to the client in an unsolicited FETCH response. 105 This allows a client to be passive recipient of events and new mail, 106 and be able to maintain full synchronisation without having to issue 107 any subsequent commands except to modify the state of the mailbox on 108 the server. 110 Some mobile clients, however, may want mail "pushed" only for mail 111 that matches a SEARCH pattern. To meet that need [CONTEXT] is 112 augmented by this document to extend the UPDATE return option to 113 specify a list of fetch-atts to be returned when a new message is 114 delivered or appended in another session. 116 [[Should the following be a normative subsection?]] IMAP servers 117 which support this extension advertise the X-DRAFT-W03-NOTIFY 118 extension. 120 A server implementing this extension is not required to implement 121 LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must 122 be able to return extended LIST responses defined in [LISTEXT]. 124 [[RFC-Editor: Please delete the following before publication: 125 Comments regarding this draft may be sent either to the 126 lemonade@ietf.org mailing list or to the authors.]] 128 3. The NOTIFY Command 130 Arguments: "ADD" or "SET" 131 optional STATUS indicator 132 Mailboxes to be watched 133 Events about which to notify the client 135 Or 136 Arguments: "NONE" 138 Responses: Possibly untagged STATUS responses (for ADD/SET) 140 Result: OK - The server will notify the client as requested. 141 NO - Unsupported notify event, NOTIFY too complex or 142 expensive, etc. 143 BAD - Command unknown, invalid, unsupported or unknown 145 Internet-draft February 2008 147 arguments. 149 The NOTIFY command informs the server that the client listens for 150 event notifications all the time (even when no command is in 151 progress) and requests the server to notify it about the specified 152 set of events. The NOTIFY command has 3 forms. The NOTIFY NONE 153 specifies that the client is not interested in any kind of event 154 happening on the server. The NOTIFY ADD prepends one or more events 155 to the list of events which are interesting to the client. The 156 NOTIFY SET replaces the current list of interesting events with a 157 new list of events. (Note that NOTIFY SET is effectively 158 the same as NOTIFY NONE followed by NOTIFY ADD .) 160 Until the NOTIFY command is used for the first time, the server only 161 sends notifications while a command is being processed, and notifies 162 the client about these events on the selected mailbox: (see section 163 5 for definitions): MessageNew, MessageExpunge, FlagChange. It does 164 not notify the client about any events on other mailboxes. 166 The effect of a successful NOTIFY command lasts until the next 167 NOTIFY command, or until the IMAP connection is closed. 169 A successful NOTIFY ADD/SET command MUST cause the server to 170 immediately return any accumulated changes to the mailbox (if any), 171 such as flag changes, new or expunged messages. This is equivalent 172 to NOOP command being issued by the client just before the NOTIFY 173 ADD/SET command. 175 If the NOTIFY command enables MessageNew, MessageExpunge, 176 AnnotationChange or FlagChange notification for a mailbox, and the 177 client has specified the STATUS indicator parameter, then the server 178 MUST send a STATUS response for that mailbox before NOTIFY's tagged 179 OK. If MessageNew is enabled, the STATUS response MUST contain 180 MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the 181 STATUS response MUST contain MESSAGES. If either AnnotationChange or 182 FlagChange are included, the STATUS response MUST contain 183 UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator 184 parameter allows the client to avoid the additional STATUS 185 responses. This might be useful if the client has already retrieved 186 this information before issuing the NOTIFY command. 188 Clients are advised to limit the number of mailboxes used with 189 NOTIFY. Particularly, if a client asks for events for all accessible 190 mailboxes, the server may swamp the client with updates about shared 191 mailboxes. This wastes both server and network resources. For 192 each mailbox specified, the server verifies that the client has 193 access using the following test: 195 Internet-draft February 2008 197 - If the name does not refer to an existing mailbox, the server MUST 198 ignore it. 200 - If the name refers to a mailbox which the client can't LIST, the 201 server MUST ignore it. For a server that implements [RFC4314] this 202 means that if the client that doesn't have the 'l' (lookup) right 203 for the name, then the server MUST ignore the mailbox. This 204 behavior prevents dislosure on potentially confidential 205 information to clients which don't have rights to know it. 207 - If the name refers to a mailbox which the client can LIST (e.g. it 208 has the 'l' right from [RFC4314]), but misses another right 209 required for processing of the specified event(s), then the server 210 MUST respond with an untagged extended LIST response containing 211 the \NoAccess name attribute. [[Alexey: Note, the newly defined 212 \NoAccess doesn't mean that the client doesn't have any rights 213 other than 'l'. The \NoAccess is only meaningful in the context of 214 the specified NOTIFY command.]] 216 The server SHOULD return the tagged OK response if the client has 217 access to at least one of the mailboxes specified in the current 218 list of interesting events. The server MAY return the tagged NO 219 response if the client has no access to any of the specified 220 mailboxes and no access can ever be granted in the future (e.g. the 221 client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't 222 exist and LIST returns \Noinferiors for the parent 'Bar'). 224 If the notification would be prohibitively expensive for the server 225 (e.g. "notify me of all flag changes in all mailboxes"), the server 226 MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] 227 response. 229 If the client requests information for events of an unsupported 230 type, the server MUST refuse the command with a tagged NO response 231 (not a BAD). This response SHOULD contain the BADEVENT response 232 code, which MUST list names of all events supported by the server. 234 Here's an example: 236 S: * OK [CAPABILITY IMAP4REV1 NOTIFY] 237 C: a login bob alice 238 S: a OK Password matched 239 C: b notify set status (selected MessageNew (uid 240 body.peek[header.fields (from to subject)]) MessageExpunge) 241 (subtree Lists MessageNew) 242 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 243 500) 244 S: [...] 246 Internet-draft February 2008 248 S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) 249 S: b OK done 250 C: c select inbox 251 S: [...] (the usual 7-8 responses to SELECT) 252 S: c OK INBOX selected 253 (Time passes. A new message is delivered to mailbox 254 Lists/Lemonade.) 255 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 256 MESSAGES 501) 257 (Time passes. A new message is delivered to inbox.) 258 S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To 259 Subject)] {75} 260 S: Subject: Re: good morning 261 S: From: alice@example.org 262 S: To: bob@example.org 263 S: 264 S: ) 265 (Time passes. The client decides it wants to know about 266 one more mailbox.) 267 C: d notify add status (mailboxes misc MessageNew) 268 S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) 269 (This command enables notification on one mailbox and 270 otherwise changes nothing, so one STATUS response is 271 sent.) 272 S: d OK done 274 4. Interaction with the IDLE Command 276 If IDLE (as well as this extension) is supported, while processing 277 IDLE the server MUST send the same events as instructed by the 278 client using the NOTIFY command. 280 NOTIFY makes IDLE unnecessary for some clients. If a client does not 281 use MSNs and '*' in commands, it can request MessageExpunge and 282 MessageNew for the selected mailbox using the NOTIFY command instead 283 of entering the IDLE mode. 285 5. Event Types 287 Only some of the events in [MSGEVENT] can be expressed in IMAP, and 288 for some of them there are several possible ways to express the 289 event. 291 This section specifies the events which an IMAP server can notify an 292 IMAP client, and how. 294 Internet-draft February 2008 296 The server SHOULD omit notifying the client if the event is caused 297 by this client. For example, if the client issues CREATE and has 298 requested MailboxName event that would cover the newly created 299 mailbox, the server SHOULD NOT notify the client of the MailboxName 300 change. 302 All event types described in this document require the 'l' and 'r' 303 rights (see [RFC4314]) on all observed mailboxes. Servers that 304 don't implement [RFC4314] should map the above rights to their 305 access control model. 307 If the client instructs the server not to send MessageNew or 308 MessageExpunge for the selected mailbox, the server MUST still send 309 EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] 310 section 7). In other words, MessageExpunge instructs the server to 311 notify the client immediately, and the lack of MessageExpunge 312 instructs the server to notify the client during execution of the 313 next command as specified in [RFC3501]. MessageNew is handled 314 similarly by the server. 316 5.1. FlagChange and AnnotationChange 318 If the flag/annotation change happens in the selected mailbox, the 319 server MUST notify the client by sending an unsolicited FETCH 320 response, which MUST include UID and FLAGS/ANNOTATION FETCH data 321 items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...] 322 responses. 324 If a search context is in effect as specified in [CONTEXT], an 325 ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if 326 appropriate. [[Alexey: I don't think this is needed: In this case, 327 the FETCH response MUST precede the ESEARCH response.]] 329 If the change happens in another mailbox, then the response depends 330 on whether CONDSTORE [RFC4551] is being used. If so, the server 331 sends a STATUS (HIGHESTMODSEQ) response. Note that whenever mailbox 332 UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the 333 STATUS response. If CONDSTORE is not used, the server does not 334 notify the client. 336 FlagChange covers the MessageRead, MessageTrash, FlagsSet and 337 FlagsClear events in [MSGEVENT]. 339 [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent 340 for MessageRead. Arnt considers that unsound, since it involves 341 processing all messages in a mailbox after an event affecting only 342 one message, and since it's not reliable anyway.]] 344 Internet-draft February 2008 346 Example in the selected mailbox: 347 S: * 99 FETCH (UID 9999 FLAGS ($Junk)) 349 And in another, with CONDSTORE in use: 350 S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) 352 5.2. MessageNew 354 This covers both MessageNew and MessageAppend in [MSGEVENT]. 356 If the new/appended message is in the selected mailbox, the server 357 notifies the client by sending an unsolicited EXISTS response, 358 followed by an unsolicited FETCH response containing the information 359 requested by the client. A FETCH response SHOULD NOT be generated 360 for a new message created by the client on this particular 361 connection, for instance as the result of an APPEND or COPY command 362 to the selected mailbox performed by the client itself. The server 363 MAY also send a RECENT response, if the server marks the message as 364 \Recent. 366 Note that a single EXISTS response can be returned for multiple 367 MessageAppend/MessageNew events. 369 If a search context is in effect as specified in [CONTEXT], an 370 ESEARCH ADDTO will also be generated, if appropriate. In this case, 371 the EXISTS response MUST precede the ESEARCH response. Both the 372 NOTIFY command and the SEARCH and SORT commands (see Section 7) can 373 specify attributes to be returned for new messages. These 374 attributes SHOULD be combined into a single FETCH response. The 375 server SHOULD avoid sending duplicate data. The FETCH response(s) 376 MUST follow any ESEARCH ADDTO responses. 378 If the new/appended message is in another mailbox, the server sends 379 an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant 380 mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the 381 HIGHESTMODSEQ status data item MUST be included in the STATUS 382 response. 384 The client SHOULD NOT use FETCH attributes that implicitly set the 385 \seen flag, or that presuppose the existence of a given bodypart. 386 UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and 387 BODY/BODYSTRUCTURE may be the most useful attributes. 389 Note that if a client asks to be notified of MessageNew events, the 390 number of messages can increase at any time, and therefore the 391 client cannot refer to a specific message using the MSN/UID '*'. 393 Internet-draft February 2008 395 Example in the selected mailbox: 396 S: * 444 EXISTS 397 S: * 444 FETCH (UID 9999) 399 And in another, without CONDSTORE: 400 S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) 402 5.3. MessageExpunge 404 If the expunged message(s) is/are in the selected mailbox, the 405 server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] 406 is being used). 408 If a search context is in effect as specified in [CONTEXT], an 409 ESEARCH REMOVEFROM will also be generated, if appropriate. 411 If the expunged message(s) is/are in another mailbox, the server 412 sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the 413 relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be 414 included in the STATUS response. 416 Note that if a client requests MessageExpunge, the meaning of a MSN 417 can change at any time, so the client cannot use MSNs in commands 418 anymore. For example, such a client cannot use FETCH, but it has to 419 use UID FETCH. The meaning of '*' can also change when messages are 420 added or expunged. A client wishing to keep using MSNs MUST NOT 421 request the MessageExpunge event. 423 The MessageExpunge notification covers both MessageExpunge and 424 MessageExpire events from [MSGEVENT]. 426 Example in the selected mailbox, without QRESYNC: 427 S: * 444 EXPUNGE 428 The same example in the selected mailbox, with QRESYNC: 429 S: * VANISHED 5444 430 And in another: 431 S: * STATUS misc (UIDNEXT 999 MESSAGES 554) 433 5.4. MailboxName 435 These notifications are sent if an affected mailbox name was created 436 (with CREATE), deleted (with DELETE) or renamed (with RENAME). If a 437 mailbox is created or deleted, the mailbox itself and its parent are 438 considered to be affected. 440 The server notifies the client by sending an unsolicited LIST 442 Internet-draft February 2008 444 response for each affected mailbox name. If the mailbox name does 445 not refer to a mailbox after the event, the \Nonexistent flag MUST 446 be included. 448 For each selectable [[Alexey: is "selectable" important?]] mailbox 449 renamed, the server sends an extended LIST response [LISTEXT] for 450 the new mailbox name, containing the OLDNAME extended data item with 451 the old mailbox name. When a mailbox is renamed, its children are 452 renamed too. No additional MailboxName events are sent for children 453 in this case. When INBOX is renamed, a new INBOX is assumed to be 454 created. No MailboxName event must be sent for INBOX in this case. 456 Example of a newly created mailbox: 457 S: * LIST () "/" "NewMailbox" 459 And a deleted mailbox: 460 S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox" 462 Example of a renamed mailbox: 463 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) 465 5.5. SubscriptionChange 467 The server notifies the client by sending an unsolicited LIST 468 responses for each affected mailbox name. If and only if the mailbox 469 is subscribed after the event, the \Subscribed attribute (see 470 [LISTEXT]) is included. 472 Example: 473 S: * LIST (\Subscribed) "/" "SubscribedMailbox" 475 5.6. MailboxMetadataChange 477 The server sends an unsolicited LIST response including METADATA (as 478 per Section 4.3.1 of [METADATA]). If possible, only the changed 479 metadata should be included, but if necessary, all metadata must be 480 included. 482 Example: 483 S: * LIST "/" "INBOX" (METADATA (/comment)) 485 5.7. ServerMetadataChange 487 The server sends an unsolicited METADATA response (as per Section 488 4.5.2 of [METADATA]). Only the names of changed metadata entries 490 Internet-draft February 2008 492 SHOULD be returned in such METADATA responses. 494 Example: 495 S: * METADATA (/comment) 497 5.8. Notification Overflow 499 If the server is unable or unwilling to deliver as many 500 notifications as it is being asked to, it may disable notifications 501 for some or all clients. It MUST notify these clients by sending an 502 untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a 503 NOTIFY NONE command had just been received. 505 Example: 506 S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... 508 5.9. ACL Changes 510 Even if NOTIFY succeeds, it is still possible to loose access to the 511 mailboxes monitoried at a later time. If this happens, the server 512 MUST silently stop monitoring these mailboxes. If access is later 513 granted, the server MUST restart event monitoring. 515 6. Mailbox Specification 517 Mailboxes to be monitored can be specified in several different 518 ways. 520 If the client specifies monitoring of the same mailbox several 521 times, the first specification wins. A common example is asking for 522 events on the selected mailbox and some named mailboxes. 524 In this example, the client asks for MessageExpunge events for all 525 personal mailboxes except the selected mailbox: 526 C: a notify set (selected (MessageNew (uid flags) flagchange)) 527 (personal (MessageNew FlagChange MessageExpunge)) 529 6.1. Selected 531 Selected refers to the mailbox selected using either SELECT or 532 EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP 533 connection is not in selected state, selected does not refer to any 535 Internet-draft February 2008 537 mailbox. 539 6.2. Personal 541 Personal refers to all selectable mailboxes in the user's personal 542 namespace(s). 544 6.3. Inboxes 546 Inboxes refers to all selectable mailboxes in the user's personal 547 namespace(s) to which messages may be delivered by an MDA (see 548 [EMAIL-ARCH], particularly section 4.3.3). 550 If the IMAP server cannot easily compute this set, it MUST treat 551 "inboxes" as equivalent to "personal". 553 6.4 Subscribed 555 Subscribed refers to all mailboxes subscribed by the user. 557 If the subscription list changes, the server MUST reevaluate the 558 list. 560 6.5 Subtree 562 Subtree is followed by a mailbox name or list of mailbox names. A 563 subtree refers to all selectable mailboxes which are subordinate to 564 the specified mailbox plus the mailbox itself. 566 6.6 Mailboxes 568 Mailboxes is followed by a mailbox name or a list of mailbox names. 569 The server MUST NOT do wildcard expansion. This means there is no 570 special treatment for the LIST wildcard characters ('*' and '%') if 571 they are present in mailbox names. 573 7. Extension to SEARCH and SORT commands 575 If the server that support the NOTIFY extension also supports 576 CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the 577 UPDATE return option is extended so that a client can request that 578 FETCH attributes be returned when a new message is added to the 580 Internet-draft February 2008 582 context result set. 584 For example: 585 C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO 586 FROM 587 SUBJECT)])) FROM "boss" S: * ESEARCH (TAG "a00") (COUNT 588 17) S: a00 OK [...a new message is delivered...] S: * EXISTS 589 93 S: * ESEARCH (TAG "a00") ADDTO (0 93) S: * 93 FETCH (UID 590 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)] {76} S: Subject: 591 Re: good morning S: From: myboss@example.org S: To: 592 bob@example.org S: S: ) 594 Note that the EXISTS response MUST precede the ESEARCH response, and 595 the FETCH response MUST follow the ESEARCH response. 597 No untagged FETCH response SHOULD be returned if a message becomes a 598 member of UPDATE SEARCH due to flag or annotation changes. 600 8. Formal Syntax 602 The following syntax specification uses the Augmented Backus-Naur 603 Form (ABNF) notation as specified in [RFC4234]. [RFC3501] defines 604 the non-terminals "capability", "command-auth", "mailbox", "mailbox- 605 data", "resp-text-code" and "search-key". The "modifier-update" non- 606 terminal is defined in [CONTEXT]. 608 Except as noted otherwise, all alphabetic characters are case- 609 insensitive. The use of upper or lower case characters to define 610 token strings is for editorial clarity only. Implementations MUST 611 accept these strings in a case-insensitive fashion. 613 capability =/ "X-DRAFT-W03-NOTIFY" 614 ;; [[Note to RFC Editor: change the capability 615 ;; name before publication]] 617 command-auth =/ notify 619 notify = "NOTIFY" SP 620 (notify-add / notify-set / notify-none) 622 notify-add = "ADD" [status-indicator] SP event-groups 623 ; Add (prepend) registered notification 624 ; events to the list of notification 625 ; events. Newer events override older 626 ; events. 627 [[Alexey: what about "most specific" event 628 overriding a pattern?]] 630 Internet-draft February 2008 632 notify-set = "SET" [status-indicator] SP event-groups 633 ; Replace registered notification events 634 ; with the specified list of events 636 notify-none = "NONE" 637 ; Cancel all registered notification 638 ; events. The client is not interested 639 ; in receiving any events. 641 status-indicator = SP "STATUS" 643 one-or-more-mailbox = mailbox / many-mailboxes 645 many-mailboxes = "(" mailbox *(SP mailbox) ")" 647 event-groups = event-group *(SP event-group) 649 event-group = "(" filter-mailboxes SP events ")" 651 filter-mailboxes = "selected" / "inboxes" / "personal" / 652 "subscribed" / 653 ( "subtree" SP one-or-more-mailbox ) / 654 ( "mailboxes" SP one-or-more-mailbox ) 656 events = ( "(" event *(SP event) ")" ) / "NONE" 657 ;; As in [MSGEVENT]. 658 ;; "NONE" means that the client does not wish 659 ;; to receive any events for the specified 660 ;; mailboxes. 662 event = message-event 663 / mailbox-event / user-event / event-ext 665 message-match-criteria = "(" search-key ")" 667 message-event = ( "MessageNew" [SP 668 "(" fetch-att *(SP fetch-att) ")" ] ) 669 / "MessageExpunge" 670 / "FlagChange" SP message-match-criteria 671 / "AnnotationChange" SP message-match-criteria 672 ;; "MessageNew" includes "MessageAppend" from 673 ;; [MSGEVENT]. "FlagChange" is any of 674 ;; "MessageRead", "MessageTrash", "FlagsSet", 675 ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" 676 ;; includes "MessageExpire" [MSGEVENT]. 678 Internet-draft February 2008 680 mailbox-event = "MailboxName" / 681 "SubscriptionChange" / "MailboxMetadataChange" 682 ; "SubscriptionChange" includes 683 ; MailboxSubscribe and MailboxUnSubscribe. 684 ; "MailboxName" includes MailboxCreate, 685 ; "MailboxDelete" and "MailboxRename". 687 user-event = "ServerMetadataChange" 689 event-ext = atom 690 ;; For future extensions 692 oldname-extended-item = "OLDNAME" SP "(" mailbox ")" 693 ;; Extended data item (mbox-list-extended-item) 694 ;; returned in a LIST response when a mailbox is 695 ;; renamed. 696 ;; Note 1: the OLDNAME tag can be returned 697 ;; with and without surrounding quotes, as per 698 ;; mbox-list-extended-item-tag production. 700 resp-text-code =/ "NOTIFICATIONOVERFLOW" / 701 unsupported-events-code 703 message-event-name = "MessageNew" / 704 / "MessageExpunge" / "FlagChange" / 705 "AnnotationChange" 707 event-name = message-event-name / mailbox-event / 708 user-event 710 unsupported-events-code = "BADEVENT" 711 SP "(" event-name *(SP event-name) ")" 713 modifier-update = "UPDATE" 714 [ "(" fetch-att *(SP fetch-att) ")" ] 716 9. Security considerations 718 It is very easy for a client to deny itself service using NOTIFY: 719 Asking for all events on all mailboxes may work on a small server, 720 but with a big server can swamp the client's network connection or 721 processing capability. In the worst case, the server's processing 722 could also degrade the service it offers to other clients. 724 Server authors should be aware that if a client issues requests and 725 does not listen to the resulting responses, the TCP window can 726 easily fill up, and a careless server might block. This problem 728 Internet-draft February 2008 730 exists in plain IMAP, however this extension magnifies the problem. 732 This extensions makes it possible to retrieve messages immediately 733 when they are added to the mailbox. This makes it wholly impractical 734 to delete sensitive messages using programs like imapfilter. Using 735 [SIEVE] or similar is much better. 737 10. IANA considerations 739 The IANA is requested to add NOTIFY to the list of IMAP extensions, 740 http://www.iana.org/assignments/imap4-capabilities. 742 10.1. Initial LIST-EXTENDED extended data item registrations 744 It is requested that the following entry be added to the LIST- 745 EXTENDED extended data item registry [LISTEXT]: 747 To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED 748 extended data item 750 LIST-EXTENDED extended data item tag: OLDNAME 752 LIST-EXTENDED extended data item description: The OLDNAME extended 753 data item describes the old mailbox name for the mailbox identified 754 by the LIST response. 756 Which LIST-EXTENDED option(s) (and their types) causes this extended 757 data item to be returned (if any): none 759 Published specification : RFC XXXX, Section 5.4. 761 Security considerations: none 763 Intended usage: COMMON 765 Person and email address to contact for further information: 766 Alexey Melnikov 768 Owner/Change controller: iesg@ietf.org 770 11. Acknowedgements 772 The authors gratefully acknowledge the help of Peter Coates, Dave 773 Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen and Eric 774 Burger. In particular, Peter Coates contributed lots of text and 775 useful suggestions to this document. 777 Internet-draft February 2008 779 Various examples are copied from other RFCs. 781 This document builds on one published and two unpublished drafts by 782 the same authors. 784 12. Normative References 786 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 787 Requirement Levels", RFC 2119, Harvard University, March 788 1997. 790 [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. 792 [RFC3501] Crispin, "Internet Message Access Protocol - Version 793 4rev1", RFC 3501, University of Washington, June 2003. 795 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 796 Specifications: ABNF", RFC 4234, Brandenburg 797 Internetworking, Demon Internet Ltd, October 2005. 799 [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", 800 RFC 4314, December 2005. 802 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 803 RFC 4466, Isode Ltd., April 2006. 805 [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE 806 Operation or Quick Flag Changes Resynchronization", RFC 807 4551, Isode Ltd., June 2006. 809 [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- 810 ietf-imapext-list-extensions-18 (work in progress), IBM, 811 September 2006. 813 [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- 814 annotatemore-12 (work in progress), Apple Computer, Inc., 815 December 2007. 817 [MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store 818 Events", draft-ietf-lemonade-msgevent-03.txt (work in 819 progress), Sun, July 2007. 821 [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in 822 progress, draft-cridland-imap-context-03.txt, Isode, June 823 2007. 825 Internet-draft February 2008 827 13. Informative References 829 [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering 830 Language", RFC 5228, January 2008. 832 [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick 833 Mailbox Resynchronization", draft-ietf-lemonade- 834 reconnect-client-05.txt (work in progress), February 835 2007. 837 [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- 838 email-arch-09 (work in progress), March 2007. 840 14. Authors' Addresses 842 Curtis King 843 Isode Ltd 844 5 Castle Business Village 845 36 Station Road 846 Hampton, Middlesex TW12 2BX 847 UK 849 Email: Curtis.King@isode.com 851 Alexey Melnikov 852 Isode Ltd 853 5 Castle Business Village 854 36 Station Road 855 Hampton, Middlesex TW12 2BX 856 UK 858 Email: Alexey.Melnikov@isode.com 860 Arnt Gulbrandsen 861 Oryx Mail Systems GmbH 862 Schweppermannstr. 8 863 D-81671 Muenchen 864 Germany 866 Email: arnt@oryx.com 868 Internet-draft February 2008 870 Intellectual Property Statement 872 The IETF takes no position regarding the validity or scope of any 873 Intellectual Property Rights or other rights that might be claimed 874 to pertain to the implementation or use of the technology described 875 in this document or the extent to which any license under such 876 rights might or might not be available; nor does it represent that 877 it has made any independent effort to identify any such rights. 878 Information on the procedures with respect to rights in RFC 879 documents can be found in BCP 78 and BCP 79. 881 Copies of IPR disclosures made to the IETF Secretariat and any 882 assurances of licenses to be made available, or the result of an 883 attempt made to obtain a general license or permission for the use 884 of such proprietary rights by implementers or users of this 885 specification can be obtained from the IETF on-line IPR repository 886 at http://www.ietf.org/ipr. 888 The IETF invites any interested party to bring to its attention any 889 copyrights, patents or patent applications, or other proprietary 890 rights that may cover technology that may be required to implement 891 this standard. Please address the information to the IETF at 892 ietf-ipr@ietf.org. 894 Full Copyright Statement 896 Copyright (C) The IETF Trust (2008). This document is subject to 897 the rights, licenses and restrictions contained in BCP 78, and 898 except as set forth therein, the authors retain all their rights. 900 This document and the information contained herein are provided on 901 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 902 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 903 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 904 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 905 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 906 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 907 FOR A PARTICULAR PURPOSE. 909 Acknowledgment 911 Funding for the RFC Editor function is currently provided by the 912 Internet Society.