idnits 2.17.1 draft-ietf-lemonade-imap-notify-02.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 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 803. 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 16 longer pages, the longest (page 16) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 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 (December 25, 2007) is 5967 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 189, 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 -- Obsolete informational reference (is this intentional?): RFC 3028 (ref. 'SIEVE') (Obsoleted by RFC 5228, RFC 5429) == 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 (~~), 8 warnings (==), 8 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 December 25, 2007 9 The IMAP NOTIFY Extension 10 draft-ietf-lemonade-imap-notify-02.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 November 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 December 2007 49 1. Conventions Used in This Document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Formal syntax is defined by [RFC4234] as extended by [RFC3501] and 56 [RFC4466]. 58 The acronym MSN stands for Message Sequence Numbers (see Section 59 2.3.1.2 of [RFC3501]). 61 Example lines prefaced by "C:" are sent by the client and ones 62 prefaced by "S:" by the server. "[...]" means elision. 64 2. Overview 66 The IDLE command (defined in [RFC2177]) provides a way for the 67 client to go into a mode where the IMAP server pushes notifications 68 about IMAP mailstore events for the selected mailbox. However, the 69 IDLE extension doesn't restrict or control which server events can 70 be sent, or what information the server sends in response to each 71 event. Also, IDLE only applies to the selected mailbox, thus 72 requiring an additional TCP connection per mailbox. 74 This document defines an IMAP extension that allows clients to 75 express their preferences about unsolicited events generated by the 76 server. The extension allows clients to only receive events they 77 are interested in, while servers know that they don't need to go 78 into effort of generating certain types of untagged responses. 80 IMAP servers which support this extension advertise the X-DRAFT- 81 W00-NOTIFY extension. 83 A server implementing this extension is not required to implement 84 LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must 85 be able to return extended LIST responses defined in [LISTEXT]. 87 Comments regarding this draft may be sent either to the 88 lemonade@ietf.org mailing list or to the authors. 90 3. The NOTIFY Command 92 Arguments: "ADD" or "SET" 93 optional STATUS indicator 94 Mailboxes to be watched 96 Internet-draft December 2007 98 Events about which to notify the client 100 Or 101 Arguments: "NONE" 103 Responses: Possibly untagged STATUS responses (for ADD/SET) 105 Result: OK - The server will notify the client as requested. 106 NO - Unsupported notify event, NOTIFY too complex or 107 expensive, etc. 108 BAD - Command unknown, invalid, unsupported or unknown 109 arguments. 111 The NOTIFY command informs the server that the client listens for 112 event notifications all the time (even when no command is in 113 progress) and requests the server to notify it about the specified 114 set of events. The NOTIFY command has 3 forms. The NOTIFY NONE 115 specifies that the client is not interested in any kind of event 116 happening on the server. The NOTIFY ADD prepends one or more events 117 to the list of events which are interesting to the client. The 118 NOTIFY SET replaces the current list of interesting events with a 119 new list of events. (Note that NOTIFY SET is effectively 120 the same as NOTIFY NONE followed by NOTIFY ADD .) 122 Until the NOTIFY command is used for the first time, the server only 123 sends notifications while a command is being processed, and notifies 124 the client about these events on the selected mailbox: (see section 125 5 for definitions): MessageNew, MessageExpunge, FlagChange. It does 126 not notify the client about any events on other mailboxes. 128 The effect of a successful NOTIFY command lasts until the next 129 NOTIFY command, or until the IMAP connection is closed. 131 A successful NOTIFY ADD/SET command MUST cause the server to 132 immediately return any accumulated changes to the mailbox (if any), 133 such as flag changes, new or expunged messages. This is equivalent 134 to NOOP command being issued by the client just before the NOTIFY 135 ADD/SET command. 137 If the NOTIFY command enables MessageNew, MessageExpunge, 138 AnnotationChange or FlagChange notification for a mailbox, and the 139 client has specified the STATUS indicator parameter, then the server 140 MUST send a STATUS response for that mailbox before NOTIFY's tagged 141 OK. If MessageNew is enabled, the STATUS response MUST contain 142 MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the 143 STATUS response MUST contain MESSAGES. If either AnnotationChange or 144 FlagChange are included, the STATUS response MUST contain 145 UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator 147 Internet-draft December 2007 149 parameter allows the client to avoid the additional STATUS 150 responses. This might be useful if the client has already retrieved 151 this information before issuing the NOTIFY command. 153 Clients are advised to limit the number of mailboxes used with 154 NOTIFY. Particularly, if a client asks for events for all accessible 155 mailboxes, the server may swamp the client with updates about shared 156 mailboxes. This wastes both server and network resources. For 157 each mailbox specified, the server verifies that the client has 158 access using the following test: 160 - If the name does not refer to an existing mailbox, the server MUST 161 ignore it. 163 - If the name refers to a mailbox which the client can't LIST, the 164 server MUST ignore it. For a server that implements [RFC4314] this 165 means that if the client that doesn't have the 'l' (lookup) right 166 for the name, then the server MUST ignore the mailbox. This 167 behavior prevents dislosure on potentially confidential 168 information to clients which don't have rights to know it. 170 - If the name refers to a mailbox which the client can LIST (e.g. it 171 has the 'l' right from [RFC4314]), but misses another right 172 required for processing of the specified event(s), then the server 173 MUST respond with an untagged extended LIST response containing 174 the \NoAccess name attribute. [[Alexey: Note, the newly defined 175 \NoAccess doesn't mean that the client doesn't have any rights 176 other than 'l'. The \NoAccess is only meaningful in the context of 177 the specified NOTIFY command.]] 179 The server SHOULD return the tagged OK response if the client has 180 access to at least one of the mailboxes specified in the current 181 list of interesting events. The server MAY return the tagged NO 182 response if the client has no access to any of the specified 183 mailboxes and no access can ever be granted in the future (e.g. the 184 client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't 185 exist and LIST returns \Noinferiors for the parent 'Bar'). 187 If the notification would be prohibitively expensive for the server 188 (e.g. "notify me of all flag changes in all mailboxes"), the server 189 MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] 190 response. 192 If the client requests information for events of an unsupported 193 type, the server MUST refuse the command with a tagged NO response 194 (not a BAD). This response SHOULD contain the BADEVENT response 195 code, which MUST list names of all events supported by the server. 197 Internet-draft December 2007 199 Here's an example: 201 S: * OK [CAPABILITY IMAP4REV1 NOTIFY] 202 C: a login bob alice 203 S: a OK Password matched 204 C: b notify set status (selected MessageNew (uid 205 body.peek[header.fields (from to subject)]) (all) 206 MessageExpunge) (subtree Lists MessageNew (uid) (all)) 207 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 208 500) 209 S: [...] 210 S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) 211 S: b OK done 212 C: c select inbox 213 S: [...] (the usual 7-8 responses to SELECT) 214 S: c OK INBOX selected 215 (Time passes. A new message is delivered to mailbox 216 Lists/Lemonade.) 217 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 218 MESSAGES 501) 219 (Time passes. A new message is delivered to inbox.) 220 S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To 221 Subject)] {75} 222 S: Subject: Re: good morning 223 S: From: alice@example.org 224 S: To: bob@example.org 225 S: 226 S: ) 227 (Time passes. The client decides it wants to know about 228 one more mailbox.) 229 C: d notify add status (mailboxes misc MessageNew (uid) (all)) 230 S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) 231 (This command enables notification on one mailbox and 232 otherwise changes nothing, so one STATUS response is 233 sent.) 234 S: d OK done 236 4. Interaction with the IDLE Command 238 If IDLE (as well as this extension) is supported, while processing 239 IDLE the server MUST send the same events as instructed by the 240 client using the NOTIFY command. 242 NOTIFY makes IDLE unnecessary for some clients. If a client does not 243 use MSNs and '*' in commands, it can request MessageExpunge and 244 MessageNew for the selected mailbox using the NOTIFY command instead 245 of entering the IDLE mode. 247 Internet-draft December 2007 249 5. Event Types 251 Only some of the events in [MSGEVENT] can be expressed in IMAP, and 252 for some of them there are several possible ways to express the 253 event. 255 This section specifies the events which an IMAP server can notify an 256 IMAP client, and how. 258 The server SHOULD omit notifying the client if the event is caused 259 by this client. For example, if the client issues CREATE and has 260 requested MailboxName event that would cover the newly created 261 mailbox, the server SHOULD NOT notify the client of the MailboxName 262 change. 264 All event types described in this document require the 'l' and 'r' 265 rights (see [RFC4314]) on all observed mailboxes. Servers that 266 don't implement [RFC4314] should map the above rights to their 267 access control model. 269 If the client instructs the server not to send MessageNew or 270 MessageExpunge for the selected mailbox, the server MUST still send 271 EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] 272 section 7). In other words, MessageExpunge instructs the server to 273 notify the client immediately, and the lack of MessageExpunge 274 instructs the server to notify the client during execution of the 275 next command as specified in [RFC3501]. MessageNew is handled 276 similarly by the server. 278 5.1. FlagChange and AnnotationChange 280 If the flag/annotation change happens in the selected mailbox, the 281 server MUST notify the client by sending an unsolicited FETCH 282 response, which MUST include UID and FLAGS/ANNOTATION FETCH data 283 items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...] 284 responses. 286 If the change happens in another mailbox, then the response depends 287 on whether CONDSTORE [RFC4551] is being used. If so, the server 288 sends a STATUS (HIGHESTMODSEQ) response. Note that whenever mailbox 289 UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the 290 STATUS response. If CONDSTORE is not used, the server does not 291 notify the client. 293 FlagChange covers the MessageRead, MessageTrash, FlagsSet and 294 FlagsClear events in [MSGEVENT]. 296 Internet-draft December 2007 298 [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent 299 for MessageRead. Arnt considers that unsound, since it involves 300 processing all messages in a mailbox after an event affecting only 301 one message, and since it's not reliable anyway.]] 303 Example in the selected mailbox: 304 S: * 99 FETCH (UID 9999 FLAGS ($Junk)) 306 And in another, with CONDSTORE in use: 307 S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) 309 5.2. MessageNew 311 This covers both MessageNew and MessageAppend in [MSGEVENT]. 313 If the new/appended message is in the selected mailbox, the server 314 notifies the client by sending an unsolicited EXISTS response, 315 followed by an unsolicited FETCH response containing the information 316 requested by the client. The server MAY also send a RECENT response, 317 if the server marks the message as \Recent. 319 Note that a single EXISTS response can be returned for multiple 320 MessageAppend/MessageNew events. 322 If the new/appended message is in another mailbox, the server sends 323 an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant 324 mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the 325 HIGHESTMODSEQ status data item MUST be included in the STATUS 326 response. 328 The client SHOULD NOT use FETCH attributes that implicitly set the 329 \seen flag, or that presuppose the existence of a given bodypart. 330 UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and 331 BODY/BODYSTRUCTURE may be the most useful attributes. 333 Note that if a client asks to be notified of MessageNew events, the 334 number of messages can increase at any time, and therefore the 335 client cannot refer to a specific message using the MSN/UID '*'. 337 Example in the selected mailbox: 338 S: * 444 EXISTS 339 S: * 444 FETCH (UID 9999) 341 And in another, without CONDSTORE: 342 S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) 344 Internet-draft December 2007 346 5.3. MessageExpunge 348 If the expunged message(s) is/are in the selected mailbox, the 349 server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] 350 is being used). 352 If the expunged message(s) is/are in another mailbox, the server 353 sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the 354 relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be 355 included in the STATUS response. 357 Note that if a client requests MessageExpunge, the meaning of a MSN 358 can change at any time, so the client cannot use MSNs in commands 359 anymore. For example, such a client cannot use FETCH, but it has to 360 use UID FETCH. The meaning of '*' can also change when messages are 361 added or expunged. A client wishing to keep using MSNs MUST NOT 362 request the MessageExpunge event. 364 The MessageExpunge notification covers both MessageExpunge and 365 MessageExpire events from [MSGEVENT]. 367 Example in the selected mailbox, without QRESYNC: 368 S: * 444 EXPUNGE 369 The same example in the selected mailbox, with QRESYNC: 370 S: * VANISHED 5444 371 And in another: 372 S: * STATUS misc (UIDNEXT 999 MESSAGES 554) 374 5.4. MailboxName 376 These notifications are sent if an affected mailbox name was created 377 (with CREATE), deleted (with DELETE) or renamed (with RENAME). If a 378 mailbox is created or deleted, the mailbox itself and its parent are 379 considered to be affected. 381 The server notifies the client by sending an unsolicited LIST 382 response for each affected mailbox name. If the mailbox name does 383 not refer to a mailbox after the event, the \Nonexistent flag MUST 384 be included. 386 For each selectable [[Alexey: is "selectable" important?]] mailbox 387 renamed, the server sends an extended LIST response [LISTEXT] for 388 the new mailbox name, containing the OLDNAME extended data item with 389 the old mailbox name. When a mailbox is renamed, its children are 390 renamed too. No additional MailboxName events are sent for children 391 in this case. When INBOX is renamed, a new INBOX is assumed to be 392 created. No MailboxName event must be sent for INBOX in this case. 394 Internet-draft December 2007 396 Example of a newly created mailbox: 397 S: * LIST () "/" "NewMailbox" 399 And a deleted mailbox: 400 S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox" 402 Example of a renamed mailbox: 403 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) 405 5.5. SubscriptionChange 407 The server notifies the client by sending an unsolicited LIST 408 responses for each affected mailbox name. If and only if the mailbox 409 is subscribed after the event, the \Subscribed attribute (see 410 [LISTEXT]) is included. 412 Example: 413 S: * LIST (\Subscribed) "/" "SubscribedMailbox" 415 5.6. MailboxMetadataChange 417 The server sends an unsolicited LIST response including METADATA (as 418 per Section 4.3.1 of [METADATA]). If possible, only the changed 419 metadata should be included, but if necessary, all metadata must be 420 included. 422 Example: 423 S: * LIST "/" "INBOX" (METADATA (/comment)) 425 5.7. ServerMetadataChange 427 The server sends an unsolicited METADATA response (as per Section 428 4.5.2 of [METADATA]). Only the names of changed metadata entries 429 SHOULD be returned in such METADATA responses. 431 Example: 432 S: * METADATA (/comment) 434 5.8. Notification Overflow 436 If the server is unable or unwilling to deliver as many 437 notifications as it is being asked to, it may disable notifications 438 for some or all clients. It MUST notify these clients by sending an 440 Internet-draft December 2007 442 untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a 443 NOTIFY NONE command had just been received. 445 Example: 446 S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... 448 5.9. ACL Changes 450 Even if NOTIFY succeeds, it is still possible to loose access to the 451 mailboxes monitoried at a later time. If this happens, the server 452 MUST silently stop monitoring these mailboxes. If access is later 453 granted, the server MUST restart event monitoring. 455 6. Mailbox Specification 457 Mailboxes to be monitored can be specified in several different 458 ways. 460 If the client specifies monitoring of the same mailbox several 461 times, the first specification wins. A common example is asking for 462 events on the selected mailbox and some named mailboxes. 464 In this example, the client asks for MessageExpunge events for all 465 personal mailboxes except the selected mailbox: 466 C: a notify set (selected (MessageNew (uid flags) flagchange)) 467 (personal (MessageNew (uid flags) flagchange MessageExpunge)) 469 6.1. Selected 471 Selected refers to the mailbox selected using either SELECT or 472 EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP 473 connection is not in selected state, selected does not refer to any 474 mailbox. 476 6.2. Personal 478 Personal refers to all selectable mailboxes in the user's personal 479 namespace(s). 481 6.3. Inboxes 483 Inboxes refers to all selectable mailboxes in the user's personal 485 Internet-draft December 2007 487 namespace(s) to which messages may be delivered by an MDA (see 488 [EMAIL-ARCH], particularly section 4.3.3). 490 If the IMAP server cannot easily compute this set, it MUST treat 491 "inboxes" as equivalent to "personal". 493 6.4 Subscribed 495 Subscribed refers to all mailboxes subscribed by the user. 497 If the subscription list changes, the server MUST reevaluate the 498 list. 500 6.5 Subtree 502 Subtree is followed by a mailbox name or list of mailbox names. A 503 subtree refers to all selectable mailboxes which are subordinate to 504 the specified mailbox plus the mailbox itself. 506 [[Open Issue: Making this "all selectable mailboxes" makes it easy 507 to implement this well. The pattern can be evaluated at NOTIFY time 508 and notification information affixed to the mailboxes in RAM. Fine. 509 But what about "notify me if any mailboxes are created whose name 510 contains the letters xxx"? Not useful IMO...? (writes arnt)]] 512 6.6 Mailboxes 514 Mailboxes is followed by a mailbox name or a list of mailbox names. 515 The server MUST NOT do wildcard expansion. This means there is no 516 special treatment for the LIST wildcard characters ('*' and '%') if 517 they are present in mailbox names. 519 7. Formal Syntax 521 The following syntax specification uses the Augmented Backus-Naur 522 Form (ABNF) notation as specified in [RFC4234]. [RFC3501] defines 523 the non-terminals "capability", "command-auth", "mailbox", "mailbox- 524 data", "resp-text-code" and "search-key". 526 Except as noted otherwise, all alphabetic characters are case- 527 insensitive. The use of upper or lower case characters to define 528 token strings is for editorial clarity only. Implementations MUST 529 accept these strings in a case-insensitive fashion. 531 Internet-draft December 2007 533 capability =/ "X-DRAFT-W00-NOTIFY" 534 ;; [[Note to RFC Editor: change the capability 535 ;; name before publication]] 537 command-auth =/ notify 539 notify = "NOTIFY" SP 540 (notify-add / notify-set / notify-none) 542 notify-add = "ADD" [status-indicator] SP event-groups 543 ; Add (prepend) registered notification 544 ; events to the list of notification 545 ; events. Newer events override older 546 ; events. 547 [[Alexey: what about "most specific" event 548 overriding a pattern?]] 550 notify-set = "SET" [status-indicator] SP event-groups 551 ; Replace registered notification events 552 ; with the specified list of events 554 notify-none = "NONE" 555 ; Cancel all registered notification 556 ; events. The client is not interested 557 ; in receiving any events. 559 status-indicator = SP "STATUS" 561 one-or-more-mailbox = mailbox / many-mailboxes 563 many-mailboxes = "(" mailbox *(SP mailbox) ")" 565 event-groups = event-group *(SP event-group) 567 event-group = "(" filter-mailboxes SP events ")" 569 filter-mailboxes = "selected" / "inboxes" / "personal" / 570 "subscribed" / 571 ( "subtree" SP one-or-more-mailbox ) / 572 ( "mailboxes" SP one-or-more-mailbox ) 574 events = ( "(" event *(SP event) ")" ) / "NONE" 575 ;; As in [MSGEVENT]. 576 ;; "NONE" means that the client does not wish 577 ;; to receive any events for the specified 578 ;; mailboxes. 580 event = message-event 582 Internet-draft December 2007 584 / mailbox-event / user-event / event-ext 586 message-match-criteria = "(" search-key ")" 588 message-event = ( "MessageNew" SP 589 "(" fetch-att *(SP fetch-att) ")" 590 SP message-match-criteria ) 591 / "MessageExpunge" 592 / "FlagChange" SP message-match-criteria 593 / "AnnotationChange" SP message-match-criteria 594 ;; "MessageNew" includes "MessageAppend" from 595 ;; [MSGEVENT]. "FlagChange" is any of 596 ;; "MessageRead", "MessageTrash", "FlagsSet", 597 ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" 598 ;; includes "MessageExpire" [MSGEVENT]. 600 mailbox-event = "MailboxName" / 601 "SubscriptionChange" / "MailboxMetadataChange" 602 ; "SubscriptionChange" includes 603 ; MailboxSubscribe and MailboxUnSubscribe. 604 ; "MailboxName" includes MailboxCreate, 605 ; "MailboxDelete" and "MailboxRename". 607 user-event = "ServerMetadataChange" 609 event-ext = atom 610 ;; For future extensions 612 oldname-extended-item = "OLDNAME" SP "(" mailbox ")" 613 ;; Extended data item (mbox-list-extended-item) 614 ;; returned in a LIST response when a mailbox is 615 ;; renamed. 616 ;; Note 1: the OLDNAME tag can be returned 617 ;; with and without surrounding quotes, as per 618 ;; mbox-list-extended-item-tag production. 620 resp-text-code =/ "NOTIFICATIONOVERFLOW" / 621 unsupported-events-code 623 message-event-name = "MessageNew" / 624 / "MessageExpunge" / "FlagChange" / 625 "AnnotationChange" 627 event-name = message-event-name / mailbox-event / 628 user-event 630 unsupported-events-code = "BADEVENT" 631 SP "(" event-name *(SP event-name) ")" 633 Internet-draft December 2007 635 8. Security considerations 637 It is very easy for a client to deny itself service using NOTIFY: 638 Asking for all events on all mailboxes may work on a small server, 639 but with a big server can swamp the client's network connection or 640 processing capability. In the worst case, the server's processing 641 could also degrade the service it offers to other clients. 643 Server authors should be aware that if a client issues requests and 644 does not listen to the resulting responses, the TCP window can 645 easily fill up, and a careless server might block. This problem 646 exists in plain IMAP, however this extension magnifies the problem. 648 This extensions makes it possible to retrieve messages immediately 649 when they are added to the mailbox. This makes it wholly impractical 650 to delete sensitive messages using programs like imapfilter. Using 651 [SIEVE] or similar is much better. 653 9. IANA considerations 655 The IANA is requested to add NOTIFY to the list of IMAP extensions, 656 http://www.iana.org/assignments/imap4-capabilities. 658 9.1. Initial LIST-EXTENDED extended data item registrations 660 It is requested that the following entry be added to the LIST- 661 EXTENDED extended data item registry [LISTEXT]: 663 To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED 664 extended data item 666 LIST-EXTENDED extended data item tag: OLDNAME 668 LIST-EXTENDED extended data item description: The OLDNAME extended 669 data item describes the old mailbox name for the mailbox identified 670 by the LIST response. 672 Which LIST-EXTENDED option(s) (and their types) causes this extended 673 data item to be returned (if any): none 675 Published specification : RFC XXXX, Section 5.4. 677 Security considerations: none 679 Intended usage: COMMON 681 Person and email address to contact for further information: 683 Internet-draft December 2007 685 Alexey Melnikov 687 Owner/Change controller: iesg@ietf.org 689 10. Acknowedgements 691 The authors gratefully acknowledge the help of Peter Coates, Dave 692 Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen and Eric 693 Burger. Various example lines are copied from other RFCs. 695 This document builds on one published and two unpublished drafts by 696 the same authors. 698 11. Normative References 700 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 701 Requirement Levels", RFC 2119, Harvard University, March 702 1997. 704 [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. 706 [RFC3501] Crispin, "Internet Message Access Protocol - Version 707 4rev1", RFC 3501, University of Washington, June 2003. 709 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 710 Specifications: ABNF", RFC 4234, Brandenburg 711 Internetworking, Demon Internet Ltd, October 2005. 713 [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", 714 RFC 4314, December 2005. 716 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 717 RFC 4466, Isode Ltd., April 2006. 719 [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE 720 Operation or Quick Flag Changes Resynchronization", RFC 721 4551, Isode Ltd., June 2006. 723 [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", 724 draft-ietf-imapext-list-extensions-18 (work in progress), 725 IBM, September 2006. 727 [METADATA] Daboo, "IMAP METADATA Extension", 728 draft-daboo-imap-annotatemore-12 (work in progress), 729 Apple Computer, Inc., December 2007. 731 Internet-draft December 2007 733 [MSGEVENT] Newman, "Internet Message Store Events", 734 draft-ietf-lemonade-msgevent-03.txt (work in progress), 735 Sun, July 2007. 737 12. Informative References 739 [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, 740 Mirapoint Inc, January 2001. 742 [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick 743 Mailbox Resynchronization", 744 draft-ietf-lemonade-reconnect-client-05.txt (work in 745 progress), February 2007. 747 [EMAIL-ARCH] Crocker, "Internet Mail Architecture", 748 draft-crocker-email-arch-09 (work in progress), March 749 2007. 751 13. Authors' Addresses 753 Curtis King 754 Isode Ltd 755 5 Castle Business Village 756 36 Station Road 757 Hampton, Middlesex TW12 2BX 758 UK 760 Email: Curtis.King@isode.com 762 Alexey Melnikov 763 Isode Ltd 764 5 Castle Business Village 765 36 Station Road 766 Hampton, Middlesex TW12 2BX 767 UK 769 Email: Alexey.Melnikov@isode.com 771 Arnt Gulbrandsen 772 Oryx Mail Systems GmbH 773 Schweppermannstr. 8 774 D-81671 Muenchen 775 Germany 777 Email: arnt@oryx.com 779 Internet-draft December 2007 781 Intellectual Property Statement 783 The IETF takes no position regarding the validity or scope of any 784 Intellectual Property Rights or other rights that might be claimed 785 to pertain to the implementation or use of the technology described 786 in this document or the extent to which any license under such 787 rights might or might not be available; nor does it represent that 788 it has made any independent effort to identify any such rights. 789 Information on the procedures with respect to rights in RFC 790 documents can be found in BCP 78 and BCP 79. 792 Copies of IPR disclosures made to the IETF Secretariat and any 793 assurances of licenses to be made available, or the result of an 794 attempt made to obtain a general license or permission for the use 795 of such proprietary rights by implementers or users of this 796 specification can be obtained from the IETF on-line IPR repository 797 at http://www.ietf.org/ipr. 799 The IETF invites any interested party to bring to its attention any 800 copyrights, patents or patent applications, or other proprietary 801 rights that may cover technology that may be required to implement 802 this standard. Please address the information to the IETF at ietf- 803 ipr@ietf.org. 805 Full Copyright Statement 807 Copyright (C) The IETF Trust (2007). This document is subject to 808 the rights, licenses and restrictions contained in BCP 78, and 809 except as set forth therein, the authors retain all their rights. 811 This document and the information contained herein are provided on 812 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 813 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 814 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 815 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 816 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 817 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 818 FOR A PARTICULAR PURPOSE. 820 Acknowledgment 822 Funding for the RFC Editor function is currently provided by the 823 Internet Society.