idnits 2.17.1 draft-ietf-lemonade-imap-notify-04.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 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 886. 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. 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 25, 2008) is 5898 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 222, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** 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-05 == Outdated reference: A later version (-05) exists of draft-cridland-imap-context-03 == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-10 Summary: 4 errors (**), 0 flaws (~~), 6 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 25, 2008 9 The IMAP NOTIFY Extension 10 draft-ietf-lemonade-imap-notify-04.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 months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 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 mailboxes. 46 Internet-draft February 2008 48 [[Add Updates: RFC-CONTEXT to the headers]] 50 1. Conventions Used in This Document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Formal syntax is defined by [RFC5234] as extended by [RFC3501] and 57 [RFC4466]. 59 The acronym MSN stands for Message Sequence Numbers (see Section 60 2.3.1.2 of [RFC3501]). 62 Example lines prefaced by "C:" are sent by the client and ones 63 prefaced by "S:" by the server. "[...]" means elision. 65 2. Overview and rationale 67 The IDLE command (defined in [RFC2177]) provides a way for the client 68 to go into a mode where the IMAP server pushes notifications about 69 IMAP mailstore events for the selected mailbox. However, the IDLE 70 extension doesn't restrict or control which server events can be 71 sent, or what information the server sends in response to each event. 72 Also, IDLE only applies to the selected mailbox, thus requiring an 73 additional TCP connection per mailbox. 75 This document defines an IMAP extension that allows clients to 76 express their preferences about unsolicited events generated by the 77 server. The extension allows clients to only receive events they are 78 interested in, while servers know that they don't need to go into 79 effort of generating certain types of untagged responses. 81 Without the NOTIFY command defined in this document, and IMAP server 82 will only send information about mailstore changes to the client in 83 the following cases: 84 - as the result of a client command (e.g. FETCH responses to 85 a FETCH or STORE command), 86 - unsolicited responses sent just before the end of a command 87 (e.g. EXISTS or EXPUNGE) as the result of changes in other 88 sessions, and 89 - during an IDLE command. 91 The NOTIFY command extends what information may be returned in those 92 last two cases, and also permits and requires the server to send 93 information about updates between command. The NOTIFY command also 95 Internet-draft February 2008 97 allows for the client to extend what information is sent unsolicited 98 about the selected mailbox, and to request some update information to 99 be sent regarding other mailboxes. 101 For the new messages delivered to or appended to the selected 102 mailbox, the NOTIFY command can be used to request that a set of 103 attributes be sent to the client in an unsolicited FETCH response. 104 This allows a client to be passive recipient of events and new mail, 105 and be able to maintain full synchronisation without having to issue 106 any subsequent commands except to modify the state of the mailbox on 107 the server. 109 Some mobile clients, however, may want mail "pushed" only for mail 110 that matches a SEARCH pattern. To meet that need [CONTEXT] is 111 augmented by this document to extend the UPDATE return option to 112 specify a list of fetch-atts to be returned when a new message is 113 delivered or appended in another session. 115 [[Should the following be a normative subsection?]] IMAP servers 116 which support this extension advertise the X-DRAFT-W04-NOTIFY 117 extension. 119 A server implementing this extension is not required to implement 120 LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must 121 be able to return extended LIST responses defined in [LISTEXT]. 123 [[RFC-Editor: Please delete the following before publication: 124 Comments regarding this draft may be sent either to the 125 lemonade@ietf.org mailing list or to the authors.]] 127 3. The NOTIFY Command 129 Arguments: "SET" 130 optional STATUS indicator 131 Mailboxes to be watched 132 Events about which to notify the client 134 Or 135 Arguments: "NONE" 137 Responses: Possibly untagged STATUS responses (for SET) 139 Result: OK - The server will notify the client as requested. 140 NO - Unsupported notify event, NOTIFY too complex or 141 expensive, etc. 142 BAD - Command unknown, invalid, unsupported or unknown 144 Internet-draft February 2008 146 arguments. 148 The NOTIFY command informs the server that the client listens for 149 event notifications all the time (even when no command is in 150 progress) and requests the server to notify it about the specified 151 set of events. The NOTIFY command has two forms. NOTIFY NONE 152 specifies that the client is not interested in any kind of event 153 happening on the server. NOTIFY SET replaces the current list of 154 interesting events with a new list of events. 156 Until the NOTIFY command is used for the first time, the server only 157 sends notifications while a command is being processed, and notifies 158 the client about these events on the selected mailbox: (see section 5 159 for definitions): MessageNew, MessageExpunge, FlagChange. It does not 160 notify the client about any events on other mailboxes. 162 The effect of a successful NOTIFY command lasts until the next NOTIFY 163 command, or until the IMAP connection is closed. 165 A successful NOTIFY SET command MUST cause the server to immediately 166 return any accumulated changes to the mailbox (if any), such as flag 167 changes, new or expunged messages. This is equivalent to NOOP command 168 being issued by the client just before the NOTIFY SET command. 170 If the NOTIFY command enables MessageNew, MessageExpunge, 171 AnnotationChange or FlagChange notification for a mailbox, and the 172 client has specified the STATUS indicator parameter, then the server 173 MUST send a STATUS response for that mailbox before NOTIFY's tagged 174 OK. If MessageNew is enabled, the STATUS response MUST contain 175 MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the 176 STATUS response MUST contain MESSAGES. If either AnnotationChange or 177 FlagChange are included, the STATUS response MUST contain UIDVALIDITY 178 and HIGHESTMODSEQ. Absence of the STATUS indicator parameter allows 179 the client to avoid the additional STATUS responses. This might be 180 useful if the client has already retrieved this information before 181 issuing the NOTIFY command. 183 Clients are advised to limit the number of mailboxes used with 184 NOTIFY. Particularly, if a client asks for events for all accessible 185 mailboxes, the server may swamp the client with updates about shared 186 mailboxes. This wastes both server and network resources. For 187 each mailbox specified, the server verifies that the client has 188 access using the following test: 190 - If the name does not refer to an existing mailbox, the server MUST 191 ignore it. 193 - If the name refers to a mailbox which the client can't LIST, the 195 Internet-draft February 2008 197 server MUST ignore it. For a server that implements [RFC4314] this 198 means that if the client that doesn't have the 'l' (lookup) right 199 for the name, then the server MUST ignore the mailbox. This 200 behavior prevents dislosure on potentially confidential information 201 to clients which don't have rights to know it. 203 - If the name refers to a mailbox which the client can LIST (e.g. it 204 has the 'l' right from [RFC4314]), but misses another right 205 required for processing of the specified event(s), then the server 206 MUST respond with an untagged extended LIST response containing the 207 \NoAccess name attribute. [[Alexey: Note, the newly defined 208 \NoAccess doesn't mean that the client doesn't have any rights 209 other than 'l'. The \NoAccess is only meaningful in the context of 210 the specified NOTIFY command.]] 212 The server SHOULD return the tagged OK response if the client has 213 access to at least one of the mailboxes specified in the current list 214 of interesting events. The server MAY return the tagged NO response 215 if the client has no access to any of the specified mailboxes and no 216 access can ever be granted in the future (e.g. the client specified 217 an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't exist and LIST 218 returns \Noinferiors for the parent 'Bar'). 220 If the notification would be prohibitively expensive for the server 221 (e.g. "notify me of all flag changes in all mailboxes"), the server 222 MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] 223 response. 225 If the client requests information for events of an unsupported type, 226 the server MUST refuse the command with a tagged NO response (not a 227 BAD). This response SHOULD contain the BADEVENT response code, which 228 MUST list names of all events supported by the server. 230 Here's an example: 232 S: * OK [CAPABILITY IMAP4REV1 NOTIFY] 233 C: a login bob alice 234 S: a OK Password matched 235 C: b notify set status (selected MessageNew (uid 236 body.peek[header.fields (from to subject)]) MessageExpunge) 237 (subtree Lists MessageNew) 238 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 239 500) 240 S: [...] 241 S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) 242 S: b OK done 243 C: c select inbox 244 S: [...] (the usual 7-8 responses to SELECT) 246 Internet-draft February 2008 248 S: c OK INBOX selected 249 (Time passes. A new message is delivered to mailbox 250 Lists/Lemonade.) 251 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 MESSAGES 252 501) 253 (Time passes. A new message is delivered to inbox.) 254 S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To Subject)] 255 {75} 256 S: Subject: Re: good morning 257 S: From: alice@example.org 258 S: To: bob@example.org 259 S: 260 S: ) 261 (Time passes. The client decides it wants to know about 262 one more mailbox.) 263 C: d notify set status (selected MessageNew (uid 264 body.peek[header.fields (from to subject)]) MessageExpunge) 265 (subtree Lists MessageNew) (mailboxes misc MessageNew) 266 S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) 267 (This command enables notification on one mailbox and 268 otherwise changes nothing, so one STATUS response is 269 sent.[[AM: This is no longer correct.]]) 270 S: d OK done 272 4. Interaction with the IDLE Command 274 If IDLE (as well as this extension) is supported, while processing 275 IDLE the server MUST send the same events as instructed by the client 276 using the NOTIFY command. 278 NOTIFY makes IDLE unnecessary for some clients. If a client does not 279 use MSNs and '*' in commands, it can request MessageExpunge and 280 MessageNew for the selected mailbox using the NOTIFY command instead 281 of entering IDLE mode. 283 5. Event Types 285 Only some of the events in [MSGEVENT] can be expressed in IMAP, and 286 for some of them there are several possible ways to express the 287 event. 289 This section specifies the events which an IMAP server can notify an 290 IMAP client, and how. 292 The server SHOULD omit notifying the client if the event is caused by 293 this client. For example, if the client issues CREATE and has 295 Internet-draft February 2008 297 requested MailboxName event that would cover the newly created 298 mailbox, the server SHOULD NOT notify the client of the MailboxName 299 change. 301 All event types described in this document require the 'l' and 'r' 302 rights (see [RFC4314]) on all observed mailboxes. Servers that don't 303 implement [RFC4314] should map the above rights to their access 304 control model. 306 Note that MessageNew and MessageExpunge must be specified together. 307 It is not possible to specify one, but not the other. 309 If the client instructs the server not to send MessageNew and 310 MessageExpunge for the selected mailbox, the server MUST still send 311 EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] 312 section 7). In other words, MessageExpunge instructs the server to 313 notify the client immediately, and the lack of MessageExpunge 314 instructs the server to notify the client during execution of the 315 next command as specified in [RFC3501]. MessageNew is handled 316 similarly by the server. 318 5.1. FlagChange and AnnotationChange 320 If the flag/annotation change happens in the selected mailbox, the 321 server MUST notify the client by sending an unsolicited FETCH 322 response, which MUST include UID and FLAGS/ANNOTATION FETCH data 323 items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...] 324 responses. 326 If a search context is in effect as specified in [CONTEXT], an 327 ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if 328 appropriate. [[Alexey: I don't think this is needed: In this case, 329 the FETCH response MUST precede the ESEARCH response.]] 331 If the change happens in another mailbox, then the response depends 332 on whether CONDSTORE [RFC4551] is being used. If so, the server sends 333 a STATUS (HIGHESTMODSEQ) response. Note that whenever mailbox 334 UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the 335 STATUS response. If CONDSTORE is not used, the server does not 336 notify the client. 338 FlagChange covers the MessageRead, MessageTrash, FlagsSet and 339 FlagsClear events in [MSGEVENT]. 341 [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent 342 for MessageRead. Arnt considers that unsound, since it involves 343 processing all messages in a mailbox after an event affecting only 345 Internet-draft February 2008 347 one message, and since it's not reliable anyway.]] 349 Example in the selected mailbox: 350 S: * 99 FETCH (UID 9999 FLAGS ($Junk)) 352 And in another, with CONDSTORE in use: 353 S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) 355 5.2. MessageNew 357 This covers both MessageNew and MessageAppend in [MSGEVENT]. 359 If the new/appended message is in the selected mailbox, the server 360 notifies the client by sending an unsolicited EXISTS response, 361 followed by an unsolicited FETCH response containing the information 362 requested by the client. A FETCH response SHOULD NOT be generated for 363 a new message created by the client on this particular connection, 364 for instance as the result of an APPEND or COPY command to the 365 selected mailbox performed by the client itself. The server MAY also 366 send a RECENT response, if the server marks the message as \Recent. 368 Note that a single EXISTS response can be returned for multiple 369 MessageAppend/MessageNew events. 371 If a search context is in effect as specified in [CONTEXT], an 372 ESEARCH ADDTO will also be generated, if appropriate. In this case, 373 the EXISTS response MUST precede the ESEARCH response. Both the 374 NOTIFY command and the SEARCH and SORT commands (see Section 7) can 375 specify attributes to be returned for new messages. These attributes 376 SHOULD be combined into a single FETCH response. The server SHOULD 377 avoid sending duplicate data. The FETCH response(s) MUST follow any 378 ESEARCH ADDTO responses. 380 If the new/appended message is in another mailbox, the server sends 381 an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant 382 mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the 383 HIGHESTMODSEQ status data item MUST be included in the STATUS 384 response. 386 The client SHOULD NOT use FETCH attributes that implicitly set the 387 \seen flag, or that presuppose the existence of a given bodypart. 388 UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and 389 BODY/BODYSTRUCTURE may be the most useful attributes. 391 Note that if a client asks to be notified of MessageNew events, the 392 number of messages can increase at any time, and therefore the client 393 cannot refer to a specific message using the MSN/UID '*'. 395 Internet-draft February 2008 397 Example in the selected mailbox: 398 S: * 444 EXISTS 399 S: * 444 FETCH (UID 9999) 401 And in another, without CONDSTORE: 402 S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) 404 5.3. MessageExpunge 406 If the expunged message(s) is/are in the selected mailbox, the server 407 notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] is being 408 used). 410 If a search context is in effect as specified in [CONTEXT], an 411 ESEARCH REMOVEFROM will also be generated, if appropriate. 413 If the expunged message(s) is/are in another mailbox, the server 414 sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the 415 relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be 416 included in the STATUS response. 418 Note that if a client requests MessageExpunge, the meaning of a MSN 419 can change at any time, so the client cannot use MSNs in commands 420 anymore. For example, such a client cannot use FETCH, but it has to 421 use UID FETCH. The meaning of '*' can also change when messages are 422 added or expunged. A client wishing to keep using MSNs MUST NOT 423 request the MessageExpunge event. 425 The MessageExpunge notification covers both MessageExpunge and 426 MessageExpire events from [MSGEVENT]. 428 Example in the selected mailbox, without QRESYNC: 429 S: * 444 EXPUNGE 430 The same example in the selected mailbox, with QRESYNC: 431 S: * VANISHED 5444 432 And in another: 433 S: * STATUS misc (UIDNEXT 999 MESSAGES 554) 435 5.4. MailboxName 437 These notifications are sent if an affected mailbox name was created 438 (with CREATE), deleted (with DELETE) or renamed (with RENAME). If a 439 mailbox is created or deleted, the mailbox itself and its parent are 440 considered to be affected. 442 The server notifies the client by sending an unsolicited LIST 444 Internet-draft February 2008 446 response for each affected mailbox name. If the mailbox name does not 447 refer to a mailbox after the event, the \Nonexistent flag MUST be 448 included. 450 For each selectable [[Alexey: is "selectable" important?]] mailbox 451 renamed, the server sends an extended LIST response [LISTEXT] for the 452 new mailbox name, containing the OLDNAME extended data item with the 453 old mailbox name. When a mailbox is renamed, its children are 454 renamed too. No additional MailboxName events are sent for children 455 in this case. When INBOX is renamed, a new INBOX is assumed to be 456 created. No MailboxName event must be sent for INBOX in this case. 458 Example of a newly created mailbox: 459 S: * LIST () "/" "NewMailbox" 461 And a deleted mailbox: 462 S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox" 464 Example of a renamed mailbox: 465 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) 467 5.5. SubscriptionChange 469 The server notifies the client by sending an unsolicited LIST 470 responses for each affected mailbox name. If and only if the mailbox 471 is subscribed after the event, the \Subscribed attribute (see 472 [LISTEXT]) is included. 474 Example: 475 S: * LIST (\Subscribed) "/" "SubscribedMailbox" 477 5.6. MailboxMetadataChange 479 The server sends an unsolicited LIST response including METADATA (as 480 per Section 4.3.1 of [METADATA]). If possible, only the changed 481 metadata should be included, but if necessary, all metadata must be 482 included. 484 Example: 485 S: * LIST "/" "INBOX" (METADATA (/comment)) 487 5.7. ServerMetadataChange 489 The server sends an unsolicited METADATA response (as per Section 490 4.5.2 of [METADATA]). Only the names of changed metadata entries 492 Internet-draft February 2008 494 SHOULD be returned in such METADATA responses. 496 Example: 497 S: * METADATA (/comment) 499 5.8. Notification Overflow 501 If the server is unable or unwilling to deliver as many notifications 502 as it is being asked to, it may disable notifications for some or all 503 clients. It MUST notify these clients by sending an untagged "OK 504 [NOTIFICATIONOVERFLOW]" response and behave as if a NOTIFY NONE 505 command had just been received. 507 Example: 508 S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... 510 5.9. ACL Changes 512 Even if NOTIFY succeeds, it is still possible to loose access to the 513 mailboxes monitoried at a later time. If this happens, the server 514 MUST silently stop monitoring these mailboxes. If access is later 515 granted, the server MUST restart event monitoring. 517 6. Mailbox Specification 519 Mailboxes to be monitored can be specified in several different ways. 521 Only 'selected' matches the currently selected mailbox. If the client 522 specifies monitoring of the same mailbox several times, the first 523 specification wins. A common example is asking for events on the 524 selected mailbox and some named mailboxes. 526 In this example, the client asks for MessageExpunge events for all 527 personal mailboxes except the selected mailbox: 528 C: a notify set (selected (MessageNew (uid flags) flagchange)) 529 (personal (MessageNew FlagChange MessageExpunge)) 531 6.1. Selected 533 Selected refers to the mailbox selected using either SELECT or 534 EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP 535 connection is not in selected state, selected does not refer to any 537 Internet-draft February 2008 539 mailbox. 541 6.2. Personal 543 Personal refers to all selectable mailboxes in the user's personal 544 namespace(s). 546 6.3. Inboxes 548 Inboxes refers to all selectable mailboxes in the user's personal 549 namespace(s) to which messages may be delivered by an MDA (see 550 [EMAIL-ARCH], particularly section 4.3.3). 552 If the IMAP server cannot easily compute this set, it MUST treat 553 "inboxes" as equivalent to "personal". 555 6.4 Subscribed 557 Subscribed refers to all mailboxes subscribed by the user. 559 If the subscription list changes, the server MUST reevaluate the 560 list. 562 6.5 Subtree 564 Subtree is followed by a mailbox name or list of mailbox names. A 565 subtree refers to all selectable mailboxes which are subordinate to 566 the specified mailbox plus the mailbox itself. 568 6.6 Mailboxes 570 Mailboxes is followed by a mailbox name or a list of mailbox names. 571 The server MUST NOT do wildcard expansion. This means there is no 572 special treatment for the LIST wildcard characters ('*' and '%') if 573 they are present in mailbox names. 575 7. Extension to SEARCH and SORT commands 577 If the server that support the NOTIFY extension also supports 578 CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the 579 UPDATE return option is extended so that a client can request that 580 FETCH attributes be returned when a new message is added to the 582 Internet-draft February 2008 584 context result set. 586 For example: 587 C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO 588 FROM 589 SUBJECT)])) FROM "boss" S: * ESEARCH (TAG "a00") (COUNT 590 17) S: a00 OK [...a new message is delivered...] S: * EXISTS 591 93 S: * ESEARCH (TAG "a00") ADDTO (0 93) S: * 93 FETCH (UID 592 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)] {76} S: Subject: 593 Re: good morning S: From: myboss@example.org S: To: 594 bob@example.org S: S: ) 596 Note that the EXISTS response MUST precede the ESEARCH response, and 597 the FETCH response MUST follow the ESEARCH response. 599 No untagged FETCH response SHOULD be returned if a message becomes a 600 member of UPDATE SEARCH due to flag or annotation changes. 602 8. Formal Syntax 604 The following syntax specification uses the Augmented Backus-Naur 605 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the 606 non-terminals "capability", "command-auth", "mailbox", "mailbox- 607 data", "resp-text-code" and "search-key". The "modifier-update" non- 608 terminal is defined in [CONTEXT]. 610 Except as noted otherwise, all alphabetic characters are case- 611 insensitive. The use of upper or lower case characters to define 612 token strings is for editorial clarity only. Implementations MUST 613 accept these strings in a case-insensitive fashion. 615 capability =/ "X-DRAFT-W03-NOTIFY" 616 ;; [[Note to RFC Editor: change the capability 617 ;; name before publication]] 619 command-auth =/ notify 621 notify = "NOTIFY" SP 622 (notify-set / notify-none) 624 notify-set = "SET" [status-indicator] SP event-groups 625 ; Replace registered notification events 626 ; with the specified list of events [[Alexey: 627 what about "most specific" event overriding a 628 pattern?]] 630 notify-none = "NONE" 632 Internet-draft February 2008 634 ; Cancel all registered notification 635 ; events. The client is not interested 636 ; in receiving any events. 638 status-indicator = SP "STATUS" 640 one-or-more-mailbox = mailbox / many-mailboxes 642 many-mailboxes = "(" mailbox *(SP mailbox) ")" 644 event-groups = event-group *(SP event-group) 646 event-group = "(" filter-mailboxes SP events ")" 648 filter-mailboxes = "selected" / "inboxes" / "personal" / 649 "subscribed" / 650 ( "subtree" SP one-or-more-mailbox ) / 651 ( "mailboxes" SP one-or-more-mailbox ) 653 events = ( "(" event *(SP event) ")" ) / "NONE" 654 ;; As in [MSGEVENT]. 655 ;; "NONE" means that the client does not wish 656 ;; to receive any events for the specified 657 ;; mailboxes. 659 event = message-event 660 / mailbox-event / user-event / event-ext 662 message-match-criteria = "(" search-key ")" 664 message-event = ( "MessageNew" [SP 665 "(" fetch-att *(SP fetch-att) ")" ] ) 666 SP "MessageExpunge" 667 / "FlagChange" SP message-match-criteria 668 / "AnnotationChange" SP message-match-criteria 669 ;; "MessageNew" includes "MessageAppend" from 670 ;; [MSGEVENT]. "FlagChange" is any of 671 ;; "MessageRead", "MessageTrash", "FlagsSet", 672 ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" 673 ;; includes "MessageExpire" [MSGEVENT]. 675 mailbox-event = "MailboxName" / 676 "SubscriptionChange" / "MailboxMetadataChange" 677 ; "SubscriptionChange" includes 678 ; MailboxSubscribe and MailboxUnSubscribe. 679 ; "MailboxName" includes MailboxCreate, 680 ; "MailboxDelete" and "MailboxRename". 682 Internet-draft February 2008 684 user-event = "ServerMetadataChange" 686 event-ext = atom 687 ;; For future extensions 689 oldname-extended-item = "OLDNAME" SP "(" mailbox ")" 690 ;; Extended data item (mbox-list-extended-item) 691 ;; returned in a LIST response when a mailbox is 692 ;; renamed. 693 ;; Note 1: the OLDNAME tag can be returned 694 ;; with and without surrounding quotes, as per 695 ;; mbox-list-extended-item-tag production. 697 resp-text-code =/ "NOTIFICATIONOVERFLOW" / 698 unsupported-events-code 700 message-event-name = "MessageNew" / 701 / "MessageExpunge" / "FlagChange" / 702 "AnnotationChange" 704 event-name = message-event-name / mailbox-event / 705 user-event 707 unsupported-events-code = "BADEVENT" 708 SP "(" event-name *(SP event-name) ")" 710 modifier-update = "UPDATE" 711 [ "(" fetch-att *(SP fetch-att) ")" ] 713 9. Security considerations 715 It is very easy for a client to deny itself service using NOTIFY: 716 Asking for all events on all mailboxes may work on a small server, 717 but with a big server can swamp the client's network connection or 718 processing capability. In the worst case, the server's processing 719 could also degrade the service it offers to other clients. 721 Server authors should be aware that if a client issues requests and 722 does not listen to the resulting responses, the TCP window can easily 723 fill up, and a careless server might block. This problem exists in 724 plain IMAP, however this extension magnifies the problem. 726 This extensions makes it possible to retrieve messages immediately 727 when they are added to the mailbox. This makes it wholly impractical 728 to delete sensitive messages using programs like imapfilter. Using 729 [SIEVE] or similar is much better. 731 Internet-draft February 2008 733 10. IANA considerations 735 The IANA is requested to add NOTIFY to the list of IMAP extensions, 736 http://www.iana.org/assignments/imap4-capabilities. 738 10.1. Initial LIST-EXTENDED extended data item registrations 740 It is requested that the following entry be added to the LIST- 741 EXTENDED extended data item registry [LISTEXT]: 743 To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED 744 extended data item 746 LIST-EXTENDED extended data item tag: OLDNAME 748 LIST-EXTENDED extended data item description: The OLDNAME extended 749 data item describes the old mailbox name for the mailbox identified 750 by the LIST response. 752 Which LIST-EXTENDED option(s) (and their types) causes this extended 753 data item to be returned (if any): none 755 Published specification : RFC XXXX, Section 5.4. 757 Security considerations: none 759 Intended usage: COMMON 761 Person and email address to contact for further information: 762 Alexey Melnikov 764 Owner/Change controller: iesg@ietf.org 766 11. Acknowedgements 768 The authors gratefully acknowledge the help of Peter Coates, Dave 769 Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen and Eric 770 Burger. In particular, Peter Coates contributed lots of text and 771 useful suggestions to this document. 773 Various examples are copied from other RFCs. 775 This document builds on one published and two unpublished drafts by 776 the same authors. 778 12. Normative References 779 Internet-draft February 2008 781 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 782 Requirement Levels", RFC 2119, Harvard University, March 783 1997. 785 [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. 787 [RFC3501] Crispin, "Internet Message Access Protocol - Version 788 4rev1", RFC 3501, University of Washington, June 2003. 790 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax 791 Specifications: ABNF", RFC 5234, Brandenburg 792 Internetworking, THUS plc, January 2008. 794 [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", RFC 795 4314, December 2005. 797 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", RFC 798 4466, Isode Ltd., April 2006. 800 [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE 801 Operation or Quick Flag Changes Resynchronization", RFC 802 4551, Isode Ltd., June 2006. 804 [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- 805 ietf-imapext-list-extensions-18 (work in progress), IBM, 806 September 2006. 808 [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- 809 annotatemore-12 (work in progress), Apple Computer, Inc., 810 December 2007. 812 [MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store 813 Events", draft-ietf-lemonade-msgevent-05.txt (work in 814 progress), Sun, January 2008. 816 [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in 817 progress, draft-cridland-imap-context-03.txt, Isode, June 818 2007. 820 13. Informative References 822 [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering 823 Language", RFC 5228, January 2008. 825 [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick 826 Mailbox Resynchronization", draft-ietf-lemonade-reconnect- 827 client-06.txt (work in progress), September 2007. 829 Internet-draft February 2008 831 [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- 832 email-arch-10 (work in progress), February 2008. 834 14. Authors' Addresses 836 Curtis King 837 Isode Ltd 838 5 Castle Business Village 839 36 Station Road 840 Hampton, Middlesex TW12 2BX 841 UK 843 Email: Curtis.King@isode.com 845 Alexey Melnikov 846 Isode Ltd 847 5 Castle Business Village 848 36 Station Road 849 Hampton, Middlesex TW12 2BX 850 UK 852 Email: Alexey.Melnikov@isode.com 854 Arnt Gulbrandsen 855 Oryx Mail Systems GmbH 856 Schweppermannstr. 8 857 D-81671 Muenchen 858 Germany 860 Email: arnt@oryx.com 862 Internet-draft February 2008 864 Intellectual Property Statement 866 The IETF takes no position regarding the validity or scope of any 867 Intellectual Property Rights or other rights that might be claimed to 868 pertain to the implementation or use of the technology described in 869 this document or the extent to which any license under such rights 870 might or might not be available; nor does it represent that it has 871 made any independent effort to identify any such rights. Information 872 on the procedures with respect to rights in RFC documents can be 873 found in BCP 78 and BCP 79. 875 Copies of IPR disclosures made to the IETF Secretariat and any 876 assurances of licenses to be made available, or the result of an 877 attempt made to obtain a general license or permission for the use of 878 such proprietary rights by implementers or users of this 879 specification can be obtained from the IETF on-line IPR repository at 880 http://www.ietf.org/ipr. 882 The IETF invites any interested party to bring to its attention any 883 copyrights, patents or patent applications, or other proprietary 884 rights that may cover technology that may be required to implement 885 this standard. Please address the information to the IETF at 886 ietf-ipr@ietf.org. 888 Full Copyright Statement 890 Copyright (C) The IETF Trust (2008). This document is subject to the 891 rights, licenses and restrictions contained in BCP 78, and except as 892 set forth therein, the authors retain all their rights. 894 This document and the information contained herein are provided on an 895 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 896 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 897 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 898 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 899 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 900 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 902 Acknowledgment 904 Funding for the RFC Editor function is currently provided by the 905 Internet Society.