idnits 2.17.1 draft-ietf-lemonade-imap-notify-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 958. 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 20 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 21 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 (March 24, 2008) is 5848 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 239, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4551 (Obsoleted by RFC 7162) -- No information found for draft-daboo-imap- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'METADATA' == Outdated reference: A later version (-07) exists of draft-ietf-lemonade-msgevent-05 == Outdated reference: A later version (-05) exists of draft-cridland-imap-context-03 -- Obsolete informational reference (is this intentional?): RFC 5162 (ref. 'QRESYNC') (Obsoleted by RFC 7162) == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-10 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alexey Melnikov 3 Internet-Draft Isode Ltd. 4 Intended Status: Proposed Standard Arnt Gulbrandsen 5 Oryx Mail Systems GmbH 6 Curtis King 7 Isode Ltd. 8 March 24, 2008 10 The IMAP NOTIFY Extension 11 draft-ietf-lemonade-imap-notify-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 32 Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft expires in September 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document defines an IMAP extension which allows a client to 44 request specific kinds of unsolicited notifications for specified 45 mailboxes, such as messages being added to or deleted from 47 Internet-draft March 2008 49 mailboxes. 51 [[Add Updates: RFC-CONTEXT to the headers]] 53 1. Conventions Used in This Document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 Formal syntax is defined by [RFC5234] as extended by [RFC3501] and 60 [RFC4466]. 62 The acronym MSN stands for Message Sequence Numbers (see Section 63 2.3.1.2 of [RFC3501]). 65 Example lines prefaced by "C:" are sent by the client and ones 66 prefaced by "S:" by the server. "[...]" means elision. 68 2. Overview and rationale 70 The IDLE command (defined in [RFC2177]) provides a way for the 71 client to go into a mode where the IMAP server pushes notifications 72 about IMAP mailstore events for the selected mailbox. However, the 73 IDLE extension doesn't restrict or control which server events can 74 be sent, or what information the server sends in response to each 75 event. Also, IDLE only applies to the selected mailbox, thus 76 requiring an additional TCP connection per mailbox. 78 This document defines an IMAP extension that allows clients to 79 express their preferences about unsolicited events generated by the 80 server. The extension allows clients to only receive events they 81 are interested in, while servers know that they don't need to go 82 into effort of generating certain types of untagged responses. 84 Without the NOTIFY command defined in this document, an IMAP server 85 will only send information about mailstore changes to the client in 86 the following cases: 87 - as the result of a client command (e.g. FETCH responses to 88 a FETCH or STORE command), 89 - unsolicited responses sent just before the end of a command 90 (e.g. EXISTS or EXPUNGE) as the result of changes in other 91 sessions, and 92 - during an IDLE command. 94 The NOTIFY command extends what information may be returned in those 96 Internet-draft March 2008 98 last two cases, and also permits and requires the server to send 99 information about updates between command. The NOTIFY command also 100 allows for the client to extend what information is sent unsolicited 101 about the selected mailbox, and to request some update information 102 to be sent regarding other mailboxes. 104 For the new messages delivered to or appended to the selected 105 mailbox, the NOTIFY command can be used to request that a set of 106 attributes be sent to the client in an unsolicited FETCH response. 107 This allows a client to be passive recipient of events and new mail, 108 and be able to maintain full synchronisation without having to issue 109 any subsequent commands except to modify the state of the mailbox on 110 the server. 112 Some mobile clients, however, may want mail "pushed" only for mail 113 that matches a SEARCH pattern. To meet that need [CONTEXT] is 114 augmented by this document to extend the UPDATE return option to 115 specify a list of fetch-atts to be returned when a new message is 116 delivered or appended in another session. 118 [[RFC-Editor: Please delete the following before publication: 119 Comments regarding this draft may be sent either to the 120 lemonade@ietf.org mailing list or to the authors.]] 122 3. The NOTIFY extension 124 IMAP servers which support this extension advertise the X-DRAFT- 125 W05-NOTIFY capability. This extension adds the NOTIFY command as 126 defined in Section 5.1. 128 A server implementing this extension is not required to implement 129 LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must 130 be able to return extended LIST responses defined in [LISTEXT]. 132 [[RFC-Editor: Should QRESYNC be a required dependency for this 133 extension?]] 135 3.1. The NOTIFY Command 137 Arguments: "SET" 138 optional STATUS indicator 139 Mailboxes to be watched 140 Events about which to notify the client 142 Internet-draft March 2008 144 Or 145 Arguments: "NONE" 147 Responses: Possibly untagged STATUS responses (for SET) 149 Result: OK - The server will notify the client as requested. 150 NO - Unsupported notify event, NOTIFY too complex or 151 expensive, etc. 152 BAD - Command unknown, invalid, unsupported or unknown 153 arguments. 155 The NOTIFY command informs the server that the client listens for 156 event notifications all the time (even when no command is in 157 progress) and requests the server to notify it about the specified 158 set of events. The NOTIFY command has two forms. NOTIFY NONE 159 specifies that the client is not interested in any kind of event 160 happening on the server. NOTIFY SET replaces the current list of 161 interesting events with a new list of events. 163 Until the NOTIFY command is used for the first time, the server only 164 sends notifications while a command is being processed, and notifies 165 the client about these events on the selected mailbox: (see section 166 5 for definitions): MessageNew, MessageExpunge, FlagChange. It does 167 not notify the client about any events on other mailboxes. 169 The effect of a successful NOTIFY command lasts until the next 170 NOTIFY command, or until the IMAP connection is closed. 172 A successful NOTIFY SET command MUST cause the server to immediately 173 return any accumulated changes to the currently selected mailbox (if 174 any), such as flag changes, new or expunged messages. This is 175 equivalent to NOOP command being issued by the client just before 176 the NOTIFY SET command. 178 The NOTIFY SET command can request notifications of changes to the 179 selected mailbox, whatever it may be at the time the notifications 180 are being generated. This is done by specifying the SELECTED mailbox 181 selector (see Section 6.1) in the NOTIFY SET command. The client 182 can also request notifications on other mailboxes by name or by a 183 limited mailbox pattern match. The notifications returned for the 184 currently selected mailbox will be those specified by the SELECTED 185 mailbox specifier, even if the selected mailbox also appears by name 186 in the command. 188 If the NOTIFY command enables MessageNew, MessageExpunge, 189 AnnotationChange or FlagChange notification for a mailbox other than 190 SELECTED, and the client has specified the STATUS indicator 191 parameter, then the server MUST send a STATUS response for that 193 Internet-draft March 2008 195 mailbox before NOTIFY's tagged OK. If MessageNew is enabled, the 196 STATUS response MUST contain MESSAGES, UIDNEXT and UIDVALIDITY. If 197 MessageExpunge is enabled, the STATUS response MUST contain 198 MESSAGES. If either AnnotationChange or FlagChange are included and 199 the server also supports CONDSTORE [RFC4551] and/or QRESYNC 200 [QRESYNC] extension, the STATUS response MUST contain UIDVALIDITY 201 and HIGHESTMODSEQ. Absence of the STATUS indicator parameter allows 202 the client to avoid the additional STATUS responses. This might be 203 useful if the client has already retrieved this information before 204 issuing the NOTIFY command. 206 Clients are advised to limit the number of mailboxes used with 207 NOTIFY. Particularly, if a client asks for events for all accessible 208 mailboxes, the server may swamp the client with updates about shared 209 mailboxes. This wastes both server and network resources. For 210 each mailbox specified, the server verifies that the client has 211 access using the following test: 213 - If the name does not refer to an existing mailbox, the server MUST 214 ignore it. 216 - If the name refers to a mailbox which the client can't LIST, the 217 server MUST ignore it. For a server that implements [RFC4314] this 218 means that if the client that doesn't have the 'l' (lookup) right 219 for the name, then the server MUST ignore the mailbox. This 220 behavior prevents dislosure on potentially confidential 221 information to clients which don't have rights to know it. 223 - If the name refers to a mailbox which the client can LIST (e.g. it 224 has the 'l' right from [RFC4314]), but doesn't have another right 225 required for processing of the specified event(s), then the server 226 MUST respond with an untagged extended LIST response containing 227 the \NoAccess name attribute. 229 The server SHOULD return the tagged OK response if the client has 230 access to at least one of the mailboxes specified in the current 231 list of interesting events. The server MAY return the tagged NO 232 response if the client has no access to any of the specified 233 mailboxes and no access can ever be granted in the future (e.g. the 234 client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't 235 exist and LIST returns \Noinferiors for the parent 'Bar'). 237 If the notification would be prohibitively expensive for the server 238 (e.g. "notify me of all flag changes in all mailboxes"), the server 239 MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] 240 response. 242 If the client requests information for events of an unsupported 244 Internet-draft March 2008 246 type, the server MUST refuse the command with a tagged NO response 247 (not a BAD). This response SHOULD contain the BADEVENT response 248 code, which MUST list names of all events supported by the server. 250 Here's an example: 252 S: * OK [CAPABILITY IMAP4REV1 NOTIFY] 253 C: a login bob alice 254 S: a OK Password matched 255 C: b notify set status (selected MessageNew (uid 256 body.peek[header.fields (from to subject)]) MessageExpunge) 257 (subtree Lists MessageNew) 258 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 259 500) 260 S: [...] 261 S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) 262 S: b OK done 263 C: c select inbox 264 S: [...] (the usual 7-8 responses to SELECT) 265 S: c OK INBOX selected 266 (Time passes. A new message is delivered to mailbox 267 Lists/Lemonade.) 268 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 269 MESSAGES 501) 270 (Time passes. A new message is delivered to inbox.) 271 S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To 272 Subject)] {75} 273 S: Subject: Re: good morning 274 S: From: alice@example.org 275 S: To: bob@example.org 276 S: 277 S: ) 278 (Time passes. The client decides it wants to know about 279 one more mailbox. As the client already knows 280 necessary STATUS information for all mailboxes below 281 the Lists mailbox and because "notify set status" would 282 cause STATUS responses for *all* mailboxes specified in 283 the NOTIFY command, including the ones for which the 284 client already knows STATUS information, the client 285 issues explicit STATUS request for the mailbox to be 286 added to the watch list, followed by the NOTIFY SET 287 without the STATUS parameter.) 288 C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES) 289 S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) 290 S: d STATUS completed 291 C: e notify set (selected MessageNew (uid 292 body.peek[header.fields (from to subject)]) MessageExpunge) 293 (subtree Lists MessageNew) (mailboxes misc MessageNew) 295 Internet-draft March 2008 297 S: e OK done 299 4. Interaction with the IDLE Command 301 If IDLE (as well as this extension) is supported, while processing 302 IDLE the server MUST send the same events as instructed by the 303 client using the NOTIFY command. 305 NOTIFY makes IDLE unnecessary for some clients. If a client does not 306 use MSNs and '*' in commands, it can request MessageExpunge and 307 MessageNew for the selected mailbox using the NOTIFY command instead 308 of entering the IDLE mode. 310 5. Event Types 312 Only some of the events in [MSGEVENT] can be expressed in IMAP, and 313 for some of them there are several possible ways to express the 314 event. 316 This section specifies the events which an IMAP server can notify an 317 IMAP client, and how. 319 The server SHOULD omit notifying the client if the event is caused 320 by this client. For example, if the client issues CREATE and has 321 requested MailboxName event that would cover the newly created 322 mailbox, the server SHOULD NOT notify the client of the MailboxName 323 change. 325 All event types described in this document require the 'l' and 'r' 326 rights (see [RFC4314]) on all observed mailboxes. Servers that 327 don't implement [RFC4314] should map the above rights to their 328 access control model. 330 If FlagChange event is specified, MessageNew and MessageExpunge MUST 331 also be specified by the client. Otherwise the server MUST respond 332 with the tagged BAD response. 334 If one of MessageNew or MessageExpunge is specified, the both events 335 MUST be specified. Otherwise the server MUST respond with the 336 tagged BAD response. 338 If the client instructs the server not to send MessageNew and 339 MessageExpunge for the selected mailbox, the server MUST still send 340 EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] 341 section 7). In other words, MessageExpunge instructs the server to 342 notify the client immediately, and the lack of MessageExpunge 344 Internet-draft March 2008 346 instructs the server to notify the client during execution of the 347 next command as specified in [RFC3501]. MessageNew is handled 348 similarly by the server. 350 5.1. FlagChange and AnnotationChange 352 If the flag and/or message annotation change happens in the selected 353 mailbox, the server MUST notify the client by sending an unsolicited 354 FETCH response, which MUST include UID and FLAGS/ANNOTATION FETCH 355 data items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS 356 ...] responses. 358 If a search context is in effect as specified in [CONTEXT], an 359 ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if 360 appropriate. In this case, the FETCH response MUST precede the 361 ESEARCH response. 363 If the change happens in another mailbox, then the response depends 364 on whether CONDSTORE [RFC4551] and/or QRESYNC [QRESYNC] is being 365 used. If so, the server sends a STATUS (HIGHESTMODSEQ) response. 366 Note that whenever mailbox UIDVALIDITY changes, the server MUST also 367 include UIDVALIDITY in the STATUS response. If the number of 368 messages with \Seen flag changes, the server MAY also include the 369 UNSEEN in the STATUS response. If CONDSTORE/QRESYNC is not used and 370 the server choses not to include the UNSEEN, the server does not 371 notify the client. [[Open Issue: should there be a way to require 372 the server to return UNSEEN?]] 374 FlagChange covers the MessageRead, MessageTrash, FlagsSet and 375 FlagsClear events in [MSGEVENT]. 377 Example in the selected mailbox: 378 S: * 99 FETCH (UID 9999 FLAGS ($Junk)) 380 And in another, with CONDSTORE in use: 381 S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) 383 5.2. MessageNew 385 This covers both MessageNew and MessageAppend in [MSGEVENT]. 387 If the new/appended message is in the selected mailbox, the server 388 notifies the client by sending an unsolicited EXISTS response, 389 followed by an unsolicited FETCH response containing the information 390 requested by the client. A FETCH response SHOULD NOT be generated 391 for a new message created by the client on this particular 393 Internet-draft March 2008 395 connection, for instance as the result of an APPEND or COPY command 396 to the selected mailbox performed by the client itself. The server 397 MAY also send a RECENT response, if the server marks the message as 398 \Recent. 400 Note that a single EXISTS response can be returned for multiple 401 MessageAppend/MessageNew events. 403 If a search context is in effect as specified in [CONTEXT], an 404 ESEARCH ADDTO will also be generated, if appropriate. In this case, 405 the EXISTS response MUST precede the ESEARCH response. Both the 406 NOTIFY command and the SEARCH and SORT commands (see Section 7) can 407 specify attributes to be returned for new messages. These 408 attributes SHOULD be combined into a single FETCH response. The 409 server SHOULD avoid sending duplicate data. The FETCH response(s) 410 MUST follow any ESEARCH ADDTO responses. 412 If the new/appended message is in another mailbox, the server sends 413 an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant 414 mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the 415 HIGHESTMODSEQ status data item MUST be included in the STATUS 416 response. 418 The client SHOULD NOT use FETCH attributes that implicitly set the 419 \seen flag, or that presuppose the existence of a given bodypart. 420 UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and 421 BODY/BODYSTRUCTURE may be the most useful attributes. 423 Note that if a client asks to be notified of MessageNew events, the 424 number of messages can increase at any time, and therefore the 425 client cannot refer to a specific message using the MSN/UID '*'. 427 Example in the selected mailbox: 428 S: * 444 EXISTS 429 S: * 444 FETCH (UID 9999) 431 And in another, without CONDSTORE: 432 S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) 434 5.3. MessageExpunge 436 If the expunged message(s) is/are in the selected mailbox, the 437 server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] 438 is supported by the server and enabled by the client). 440 If a search context is in effect as specified in [CONTEXT], an 441 ESEARCH REMOVEFROM will also be generated, if appropriate. 443 Internet-draft March 2008 445 If the expunged message(s) is/are in another mailbox, the server 446 sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the 447 relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be 448 included in the STATUS response. 450 Note that if a client requests MessageExpunge, the meaning of a MSN 451 can change at any time, so the client cannot use MSNs in commands 452 anymore. For example, such a client cannot use FETCH, but it has to 453 use UID FETCH. The meaning of '*' can also change when messages are 454 added or expunged. A client wishing to keep using MSNs MUST NOT 455 request the MessageExpunge event. 457 The MessageExpunge notification covers both MessageExpunge and 458 MessageExpire events from [MSGEVENT]. 460 Example in the selected mailbox, without QRESYNC: 461 S: * 444 EXPUNGE 462 The same example in the selected mailbox, with QRESYNC: 463 S: * VANISHED 5444 464 And in another: 465 S: * STATUS misc (UIDNEXT 999 MESSAGES 554) 467 5.4. MailboxName 469 These notifications are sent if an affected mailbox name was created 470 (with CREATE), deleted (with DELETE) or renamed (with RENAME). For 471 a server that implements [RFC4314] granting or revocation of the 'l' 472 right to the current user on the affected mailbox MUST be considered 473 mailbox creation/deletion respectively. If a mailbox is created or 474 deleted, the mailbox itself and its parent are considered to be 475 affected. 477 The server notifies the client by sending an unsolicited LIST 478 response for each affected mailbox name. If, after the event, the 479 mailbox name does not refer to a mailbox accessible to the client, 480 the \Nonexistent flag MUST be included. 482 For each LISTable mailbox renamed, the server sends an extended LIST 483 response [LISTEXT] for the new mailbox name, containing the OLDNAME 484 extended data item with the old mailbox name. When a mailbox is 485 renamed, its children are renamed too. No additional MailboxName 486 events are sent for children in this case. When INBOX is renamed, a 487 new INBOX is assumed to be created. No MailboxName event must be 488 sent for INBOX in this case. 490 Example of a newly created mailbox (or granting of the 'l' right on 491 the mailbox): 493 Internet-draft March 2008 495 S: * LIST () "/" "NewMailbox" 497 And a deleted mailbox (or revocation of the 'l' right on the 498 mailbox): 499 S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox" 501 Example of a renamed mailbox: 502 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) 504 5.5. SubscriptionChange 506 The server notifies the client by sending an unsolicited LIST 507 responses for each affected mailbox name. If and only if the mailbox 508 is subscribed after the event, the \Subscribed attribute (see 509 [LISTEXT]) is included. 511 Example: 512 S: * LIST (\Subscribed) "/" "SubscribedMailbox" 514 5.6. MailboxMetadataChange 516 The server sends an unsolicited LIST response including METADATA (as 517 per Section 4.3.1 of [METADATA]). If possible, only the changed 518 metadata should be included, but if necessary, all metadata must be 519 included. 521 Example: 522 S: * LIST "/" "INBOX" (METADATA (/comment)) 524 5.7. ServerMetadataChange 526 The server sends an unsolicited METADATA response (as per Section 527 4.5.2 of [METADATA]). Only the names of changed metadata entries 528 SHOULD be returned in such METADATA responses. 530 Example: 531 S: * METADATA (/comment) 533 5.8. Notification Overflow 535 If the server is unable or unwilling to deliver as many 536 notifications as it is being asked to, it may disable notifications 537 for some or all clients. It MUST notify these clients by sending an 539 Internet-draft March 2008 541 untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a 542 NOTIFY NONE command had just been received. 544 Example: 545 S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... 547 5.9. ACL Changes 549 Even if NOTIFY succeeds, it is still possible to lose access to the 550 mailboxes monitoried at a later time. If this happens, the server 551 MUST stop monitoring these mailboxes. If access is later granted, 552 the server MUST restart event monitoring. 554 The server SHOULD return the LIST response with the \NoAccess name 555 attribute if and when the mailbox loses the 'l' right. Simalarly, 556 the server SHOULD return the LIST response with no \NoAccess name 557 attribute, if the mailbox was previously reported as having 558 \NoAccess, and later on the 'l' right is granted. 560 6. Mailbox Specification 562 Mailboxes to be monitored can be specified in several different 563 ways. 565 Only 'selected' (section 6.1) matches the currently selected 566 mailbox. All other mailbox specifications affect other (non- 567 selected) mailboxes. 569 If for any given event type the client specifies monitoring of the 570 same mailbox several times (using the same or different mailbox 571 specifications), the first specification wins. 573 Note that for different event types different s can 574 apply to the same mailbox. The following example demonstrates this. 575 In this example, MessageNew and MessageExpunge events are reported 576 for INBOX due to the first . SubscriptionChange event 577 will also be reported for INBOX due to the second . 579 C: a notify set (mailboxes INBOX (Messagenew messageExpunge)) 580 (personal (SubscriptionChange)) 582 A typical client that supports the NOTIFY extension would ask for 583 events on the selected mailbox and some named mailboxes. 585 In this example, the client asks for FlagChange events for all 587 Internet-draft March 2008 589 personal mailboxes except the selected mailbox: 590 C: a notify set (selected (Messagenew (uid flags) 591 messageExpunge)) (personal (MessageNew FlagChange 592 MessageExpunge)) 594 6.1. Selected 596 Selected refers to the mailbox selected using either SELECT or 597 EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP 598 connection is not in selected state, selected does not refer to any 599 mailbox. 601 6.2. Personal 603 Personal refers to all selectable mailboxes in the user's personal 604 namespace(s). 606 6.3. Inboxes 608 Inboxes refers to all selectable mailboxes in the user's personal 609 namespace(s) to which messages may be delivered by an MDA (see 610 [EMAIL-ARCH], particularly section 4.3.3). 612 If the IMAP server cannot easily compute this set, it MUST treat 613 "inboxes" as equivalent to "personal". 615 6.4 Subscribed 617 Subscribed refers to all mailboxes subscribed by the user. 619 If the subscription list changes, the server MUST reevaluate the 620 list. 622 6.5 Subtree 624 Subtree is followed by a mailbox name or list of mailbox names. A 625 subtree refers to all selectable mailboxes which are subordinate to 626 the specified mailbox plus the mailbox itself. 628 6.6 Mailboxes 630 Mailboxes is followed by a mailbox name or a list of mailbox names. 632 Internet-draft March 2008 634 The server MUST NOT do wildcard expansion. This means there is no 635 special treatment for the LIST wildcard characters ('*' and '%') if 636 they are present in mailbox names. 638 7. Extension to SEARCH and SORT commands 640 If the server that support the NOTIFY extension also supports 641 CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the 642 UPDATE return option is extended so that a client can request that 643 FETCH attributes be returned when a new message is added to the 644 context result set. 646 For example: 647 C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO 648 FROM 649 SUBJECT)])) FROM "boss" S: * ESEARCH (TAG "a00") (COUNT 650 17) S: a00 OK [...a new message is delivered...] S: * EXISTS 651 93 S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO 652 SUBJECT)] {76} S: Subject: Re: good morning S: From: 653 myboss@example.org S: To: bob@example.org S: S: ) S: * 654 ESEARCH (TAG "a00") ADDTO (0 93) 656 Note that the EXISTS response MUST precede any FETCH responses, and 657 together they MUST precede the ESEARCH response. 659 No untagged FETCH response SHOULD be returned if a message becomes a 660 member of UPDATE SEARCH due to flag or annotation changes. 662 8. Formal Syntax 664 The following syntax specification uses the Augmented Backus-Naur 665 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 666 the non-terminals "capability", "command-auth", "mailbox", "mailbox- 667 data", "resp-text-code" and "search-key". The "modifier-update" non- 668 terminal is defined in [CONTEXT]. "mbx-list-oflag" is defined in 669 [RFC3501] and updated by [LISTEXT]. 671 Except as noted otherwise, all alphabetic characters are case- 672 insensitive. The use of upper or lower case characters to define 673 token strings is for editorial clarity only. Implementations MUST 674 accept these strings in a case-insensitive fashion. 676 capability =/ "X-DRAFT-W05-NOTIFY" 677 ;; [[Note to RFC Editor: change the capability 678 ;; name before publication]] 680 Internet-draft March 2008 682 command-auth =/ notify 684 notify = "NOTIFY" SP 685 (notify-set / notify-none) 687 notify-set = "SET" [status-indicator] SP event-groups 688 ; Replace registered notification events 689 ; with the specified list of events 691 notify-none = "NONE" 692 ; Cancel all registered notification 693 ; events. The client is not interested 694 ; in receiving any events. 696 status-indicator = SP "STATUS" 698 one-or-more-mailbox = mailbox / many-mailboxes 700 many-mailboxes = "(" mailbox *(SP mailbox) ")" 702 event-groups = event-group *(SP event-group) 704 event-group = "(" filter-mailboxes SP events ")" 706 filter-mailboxes = "selected" / "inboxes" / "personal" / 707 "subscribed" / 708 ( "subtree" SP one-or-more-mailbox ) / 709 ( "mailboxes" SP one-or-more-mailbox ) 711 events = ( "(" event *(SP event) ")" ) / "NONE" 712 ;; As in [MSGEVENT]. 713 ;; "NONE" means that the client does not wish 714 ;; to receive any events for the specified 715 ;; mailboxes. 717 event = message-event 718 / mailbox-event / user-event / event-ext 720 message-match-criteria = "(" search-key ")" 722 message-event = ( "MessageNew" [SP 723 "(" fetch-att *(SP fetch-att) ")" ] ) 724 / "MessageExpunge" 725 / "FlagChange" SP message-match-criteria 726 / "AnnotationChange" SP message-match-criteria 727 ;; "MessageNew" includes "MessageAppend" from 728 ;; [MSGEVENT]. "FlagChange" is any of 729 ;; "MessageRead", "MessageTrash", "FlagsSet", 731 Internet-draft March 2008 733 ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" 734 ;; includes "MessageExpire" [MSGEVENT]. 735 ;; MessageNew and MessageExpunge MUST always 736 ;; be specified together. If FlagChange is 737 ;; specified, then MessageNew and MessageExpunge 738 ;; MUST be specified as well. 739 ;; The fett-att list may only be present for the 740 ;; SELECTED mailbox filter (). 742 mailbox-event = "MailboxName" / 743 "SubscriptionChange" / "MailboxMetadataChange" 744 ; "SubscriptionChange" includes 745 ; MailboxSubscribe and MailboxUnSubscribe. 746 ; "MailboxName" includes MailboxCreate, 747 ; "MailboxDelete" and "MailboxRename". 749 user-event = "ServerMetadataChange" 751 event-ext = atom 752 ;; For future extensions 754 oldname-extended-item = "OLDNAME" SP "(" mailbox ")" 755 ;; Extended data item (mbox-list-extended-item) 756 ;; returned in a LIST response when a mailbox is 757 ;; renamed. 758 ;; Note 1: the OLDNAME tag can be returned 759 ;; with and without surrounding quotes, as per 760 ;; mbox-list-extended-item-tag production. 762 resp-text-code =/ "NOTIFICATIONOVERFLOW" / 763 unsupported-events-code 765 message-event-name = "MessageNew" / 766 / "MessageExpunge" / "FlagChange" / 767 "AnnotationChange" 769 event-name = message-event-name / mailbox-event / 770 user-event 772 unsupported-events-code = "BADEVENT" 773 SP "(" event-name *(SP event-name) ")" 775 modifier-update = "UPDATE" 776 [ "(" fetch-att *(SP fetch-att) ")" ] 778 mbx-list-oflag =/ "\NoAccess" 780 Internet-draft March 2008 782 9. Security considerations 784 It is very easy for a client to deny itself service using NOTIFY: 785 Asking for all events on all mailboxes may work on a small server, 786 but with a big server can swamp the client's network connection or 787 processing capability. In the worst case, the server's processing 788 could also degrade the service it offers to other clients. 790 Server authors should be aware that if a client issues requests and 791 does not listen to the resulting responses, the TCP window can 792 easily fill up, and a careless server might block. This problem 793 exists in plain IMAP, however this extension magnifies the problem. 795 This extensions makes it possible to retrieve messages immediately 796 when they are added to the mailbox. This makes it wholly impractical 797 to delete sensitive messages using programs like imapfilter. Using 798 [SIEVE] or similar is much better. 800 10. IANA considerations 802 The IANA is requested to add NOTIFY to the list of IMAP extensions, 803 http://www.iana.org/assignments/imap4-capabilities. 805 10.1. Initial LIST-EXTENDED extended data item registrations 807 It is requested that the following entry be added to the LIST- 808 EXTENDED extended data item registry [LISTEXT]: 810 To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED 811 extended data item 813 LIST-EXTENDED extended data item tag: OLDNAME 815 LIST-EXTENDED extended data item description: The OLDNAME extended 816 data item describes the old mailbox name for the mailbox identified 817 by the LIST response. 819 Which LIST-EXTENDED option(s) (and their types) causes this extended 820 data item to be returned (if any): none 822 Published specification : RFC XXXX, Section 5.4. 824 Security considerations: none 826 Intended usage: COMMON 828 Person and email address to contact for further information: 830 Internet-draft March 2008 832 Alexey Melnikov 834 Owner/Change controller: iesg@ietf.org 836 11. Acknowedgements 838 The authors gratefully acknowledge the help of Peter Coates, Dave 839 Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen, Timo 840 Sirainen and Eric Burger. In particular, Peter Coates contributed 841 lots of text and useful suggestions to this document. 843 Various examples are copied from other RFCs. 845 This document builds on one published and two unpublished drafts by 846 the same authors. 848 12. Normative References 850 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 851 Requirement Levels", RFC 2119, Harvard University, March 852 1997. 854 [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. 856 [RFC3501] Crispin, "Internet Message Access Protocol - Version 857 4rev1", RFC 3501, University of Washington, June 2003. 859 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax 860 Specifications: ABNF", RFC 5234, Brandenburg 861 Internetworking, THUS plc, January 2008. 863 [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", 864 RFC 4314, December 2005. 866 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 867 RFC 4466, Isode Ltd., April 2006. 869 [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE 870 Operation or Quick Flag Changes Resynchronization", RFC 871 4551, Isode Ltd., June 2006. 873 [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- 874 ietf-imapext-list-extensions-18 (work in progress), IBM, 875 September 2006. 877 [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- 879 Internet-draft March 2008 881 annotatemore-12 (work in progress), Apple Computer, Inc., 882 December 2007. 884 [MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store 885 Events", draft-ietf-lemonade-msgevent-05.txt (work in 886 progress), January 2008. 888 [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in 889 progress, draft-cridland-imap-context-03.txt, Isode, June 890 2007. 892 13. Informative References 894 [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering 895 Language", RFC 5228, January 2008. 897 [QRESYNC] Melnikov, A., Cridland, D. and C. Wilson, "IMAP4 898 Extensions for Quick Mailbox Resynchronization", RFC 899 5162, March 2008. 901 [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- 902 email-arch-10 (work in progress), February 2008. 904 14. Authors' Addresses 906 Curtis King 907 Isode Ltd 908 5 Castle Business Village 909 36 Station Road 910 Hampton, Middlesex TW12 2BX 911 UK 913 Email: Curtis.King@isode.com 915 Alexey Melnikov 916 Isode Ltd 917 5 Castle Business Village 918 36 Station Road 919 Hampton, Middlesex TW12 2BX 920 UK 922 Email: Alexey.Melnikov@isode.com 924 Internet-draft March 2008 926 Arnt Gulbrandsen 927 Oryx Mail Systems GmbH 928 Schweppermannstr. 8 929 D-81671 Muenchen 930 Germany 932 Email: arnt@oryx.com 934 Internet-draft March 2008 936 Intellectual Property Statement 938 The IETF takes no position regarding the validity or scope of any 939 Intellectual Property Rights or other rights that might be claimed 940 to pertain to the implementation or use of the technology described 941 in this document or the extent to which any license under such 942 rights might or might not be available; nor does it represent that 943 it has made any independent effort to identify any such rights. 944 Information on the procedures with respect to rights in RFC 945 documents can be found in BCP 78 and BCP 79. 947 Copies of IPR disclosures made to the IETF Secretariat and any 948 assurances of licenses to be made available, or the result of an 949 attempt made to obtain a general license or permission for the use 950 of such proprietary rights by implementers or users of this 951 specification can be obtained from the IETF on-line IPR repository 952 at http://www.ietf.org/ipr. 954 The IETF invites any interested party to bring to its attention any 955 copyrights, patents or patent applications, or other proprietary 956 rights that may cover technology that may be required to implement 957 this standard. Please address the information to the IETF at 958 ietf-ipr@ietf.org. 960 Full Copyright Statement 962 Copyright (C) The IETF Trust (2008). This document is subject to 963 the rights, licenses and restrictions contained in BCP 78, and 964 except as set forth therein, the authors retain all their rights. 966 This document and the information contained herein are provided on 967 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 968 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 969 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 970 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 971 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 972 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 973 FOR A PARTICULAR PURPOSE. 975 Acknowledgment 977 Funding for the RFC Editor function is currently provided by the 978 Internet Society.