idnits 2.17.1 draft-ietf-lemonade-imap-notify-00.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 842. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 827. 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 17 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 18 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 (August 25, 2007) is 6088 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 183, but not defined == Unused Reference: 'METADATA' is defined on line 752, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2087 (Obsoleted by RFC 9208) ** 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) ** Downref: Normative reference to an Experimental draft: draft-ietf-imapext-annotate (ref. 'ANNOTATE') == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-11 == 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: 7 errors (**), 0 flaws (~~), 9 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 August 25, 2007 9 The IMAP NOTIFY Extension 10 draft-ietf-lemonade-imap-notify-00.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, such as 44 messages being added to or deleted from mailboxes. 46 Internet-draft August 2007 48 1. Conventions Used in This Document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in [RFC2119]. 54 Formal syntax is defined by [RFC4234] as extended by [RFC3501] and 55 [RFC4466]. 57 The acronym MSN stands for Message Sequence Numbers (see Section 58 2.3.1.2 of [RFC3501]). 60 Example lines prefaced by "C:" are sent by the client and ones 61 prefaced by "S:" by the server. "[...]" means elision. 63 2. Overview 65 The IDLE command (defined in [RFC2177]) provides a way for the 66 client to go into a mode where the IMAP server pushes notifications 67 about IMAP mailstore events for the selected mailbox. However, the 68 IDLE extension doesn't restrict or control which server events can 69 be sent, or what information the server sends in response to each 70 event. 72 This document defines an IMAP extension that allows clients to 73 express their preferences about unsolicited events generated by the 74 server. The extension allows clients to only receive events they 75 are interested in, while servers know that they don't need to go 76 into effort of generating certain types of untagged responses. 78 IMAP servers which support this extension advertise the X-DRAFT- 79 W00-NOTIFY extension. 81 Comments regarding this draft may be sent either to the 82 lemonade@ietf.org mailing list or to the authors. 84 3. The NOTIFY Command 86 Arguments: "ADD" or "SET" 87 optional STATUS indicator 88 Mailboxes to be watched 89 Events about which to notify the client 91 Or 92 Arguments: "NONE" 94 Internet-draft August 2007 96 Responses: Possibly untagged STATUS responses (for ADD/SET) 98 Result: OK - The server will notify the client as requested. 99 NO - NOTIFY too complex or expensive, etc. 100 BAD - Command unknown, invalid, unsupported or unknown 101 arguments. 103 The NOTIFY command informs the server that the client listens for 104 event notifications all the time (even when no command is in 105 progress) and requests the server to notify it about the specified 106 set of events. The NOTIFY command has 3 forms. The NOTIFY NONE 107 specifies that the client is not interested in any kind of event 108 happening on the server. The NOTIFY ADD prepends one or more events 109 to the list of events which are interesting to the client. The 110 NOTIFY SET replaces the current list of interesting events with a 111 new list of events. (Note that NOTIFY SET is effectively 112 the same as NOTIFY NONE followed by NOTIFY ADD .) 114 Until the NOTIFY command is used for the first time, the server only 115 sends notifications while a command is being processed, and notifies 116 the client about these events on the selected mailbox: (see section 117 5 for definitions): MessageNew, MessageExpunge, FlagChange and (if 118 [ANNOTATE] is being used) AnnotationChange. It does not notify the 119 client about any events on other mailboxes. 121 The effect of NOTIFY lasts until the next NOTIFY command, or until 122 the IMAP connection is closed. 124 A successful NOTIFY ADD/SET command MUST cause the server to 125 immediately return any accumulated changes to the mailbox (if any), 126 such as flag changes, new or expunged messages. (This is equivalent 127 to NOOP command being issued by the client just before the NOTIFY 128 ADD/SET command.) 130 If the NOTIFY command enables MessageNew, MessageExpunge, 131 AnnotationChange or FlagChange notification for a mailbox, and the 132 client has specified the STATUS indicator parameter, then the server 133 MUST send a STATUS response for that mailbox before NOTIFY's tagged 134 OK. If MessageNew is enabled, the STATUS response MUST contain 135 MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the 136 STATUS response MUST contain MESSAGES. If either AnnotationChange or 137 FlagChange are included, the STATUS response MUST contain 138 UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator 139 parameter allows the client to avoid the additional STATUS 140 responses. This might be useful if the client has already retrieved 141 this information before issuing the NOTIFY command. 143 Clients are advised to limit the number of mailboxes used with 145 Internet-draft August 2007 147 NOTIFY. Particularly, if a client asks for events for all accessible 148 mailboxes, the server may swamp the client with updates about shared 149 mailboxes. This wastes both server resources and network traffic. 151 For each mailbox specified, the server verifies that the client has 152 access using the following test: 154 - If the name does not refer to an existing mailbox, the server MUST 155 ignore it. 157 - If the name refers to a mailbox which the client can't LIST, the 158 server MUST ignore it. For a server that implements [RFC4314] this 159 means that if the client that doesn't have the 'l' (lookup) right 160 for the name, then the server MUST ignore the mailbox. This 161 behavior prevents dislosure on potentially confidential 162 information to clients which don't have rights to know it. 164 - If the name refers to a mailbox which the client can LIST (e.g. it 165 has the 'l' right from [RFC4314]), but misses another right 166 required for processing of the specified event(s), then the server 167 MUST respond with an untagged extended LIST response containing 168 the \NoAccess name attribute. [[Alexey: Note, the newly defined 169 \NoAccess doesn't mean that the client doesn't have any rights 170 other than 'l'. The \NoAccess is only meaningful in the context of 171 the specified NOTIFY command.]] 173 The server SHOULD return the tagged OK response if the client has 174 access to at least one of the mailboxes specified in the current 175 list of interesting events. The server MAY return the tagged NO 176 response if the client has no access to any of the specified 177 mailboxes and no access can ever be granted in the future (e.g. the 178 client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't 179 exist and LIST returns \Noinferiors for the parent 'Bar'). 181 If the notification would be prohibitively expensive for the server 182 (e.g. "notify me of all flag changes in all mailboxes"), the server 183 MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] 184 response. 186 If the client requests information for events of an unsupported type 187 (e.g. QuotaExceed and the server does not advertise the QUOTA 188 extension defined in [RFC2087]), the server MUST refuse the command 189 with a tagged BAD response. 191 Here's an example: 193 S: * OK [CAPABILITY IMAP4REV1 NOTIFY] 194 C: a login bob alice 196 Internet-draft August 2007 198 S: a OK Password matched 199 C: b notify set status (selected MessageNew (uid 200 body.peek[header.fields (from to subject)]) (all) 201 MessageExpunge) (subtree Lists MessageNew (uid) (all)) 202 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 203 500) 204 S: [...] 205 S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) 206 S: b OK done 207 C: c select inbox 208 S: [...] (the usual 7-8 responses to SELECT) 209 S: c OK INBOX selected 210 (Time passes. A new message is delivered to mailbox 211 Lists/Lemonade.) 212 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 213 MESSAGES 501) 214 (Time passes. A new message is delivered to inbox.) 215 S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To 216 Subject)] {75} 217 S: Subject: Re: good morning 218 S: From: alice@example.org 219 S: To: bob@example.org 220 S: 221 S: ) 222 (Time passes. The client decides it wants to know about 223 one more mailbox.) 224 C: d notify add status (mailboxes misc MessageNew (uid) (all)) 225 S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) 226 (This command enables notification on one mailbox and 227 otherwise changes nothing, so one STATUS response is 228 sent.) 229 S: d OK done 231 4. Interaction with the IDLE Command 233 If IDLE (as well as this extension) is supported, while processing 234 IDLE the server MUST send the same events as instructed by the 235 client using the NOTIFY command. 237 NOTIFY makes IDLE unnecessary for some clients. If a client does not 238 use MSNs and '*' in commands, it can request MessageExpunge and 239 MessageNew for the selected mailbox using the NOTIFY command instead 240 of entering the IDLE mode. 242 Internet-draft August 2007 244 5. Event Types 246 Only some of the events in [MSGEVENT] can be expressed in IMAP, and 247 for some of them there are several possible ways to express the 248 event. 250 This section specifies the events of which an IMAP server can notify 251 an IMAP client, and how. 253 The server SHOULD omit notifying the client if the event is caused 254 by this client. For example, if the client issues CREATE and has 255 requested MailboxCreate event that would cover the newly created 256 mailbox, the server SHOULD NOT notify the client of the 257 MailboxCreate change. 259 All event types require the 'l' and 'r' rights (see [RFC4314]) on 260 all observed mailboxes. AdminMailbox and the quota-related event 261 types additionally require the 'a' right. Servers that don't 262 implement [RFC4314] should map the above rights to their access 263 control model. 265 If the client instructs the server not to send MessageNew or 266 MessageExpunge for the selected mailbox, the server MUST still send 267 EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] 268 section 7). In other words, MessageExpunge instructs the server to 269 notify the client immediately, and the lack of MessageExpunge 270 instructs the server to notify the client during execution of the 271 next command as specified in [RFC3501]. MessageNew is handled 272 similarly by the server. 274 5.1. FlagChange and AnnotationChange 276 If the flag/annotation change happens in the selected mailbox, the 277 server notifies the client by sending an unsolicited FETCH response, 278 which MUST include UID and FLAGS/ANNOTATION FETCH data items. It MAY 279 also send new FLAGS and/or OK [PERMANENTFLAGS ...] responses. 281 If the change happens in another mailbox, then the response depends 282 on whether CONDSTORE [RFC4551] is being used. If so, the server 283 sends a STATUS (HIGHESTMODSEQ) response. (Note that whenever mailbox 284 UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the 285 STATUS response.) If not, the server does not notify the client. 287 FlagChange covers the MessageRead, MessageTrash, FlagsSet and 288 FlagsClear events in [MSGEVENT]. 290 [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent 292 Internet-draft August 2007 294 for MessageRead. Arnt considers that unsound, since it involves 295 processing all messages in a mailbox after an event affecting only 296 one message, and since it's not reliable anyway.]] 298 Example in the selected mailbox: 299 S: * 99 FETCH (UID 9999 FLAGS ($Junk)) 301 And in another, with CONDSTORE in use: 302 S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) 304 5.2. MessageNew 306 This covers both MessageNew and MessageAppend in [MSGEVENT]. 308 If the new/appended message is in the selected mailbox, the server 309 notifies the client by sending an unsolicited EXISTS response, 310 followed by an unsolicited FETCH response containing the information 311 requested by the client. The server MAY also send a RECENT response, 312 if the server marks the message as \Recent. 314 Note that a single EXISTS response can be returned for multiple 315 MessageAppend/MessageNew events. 317 If the new/appended message is in another mailbox, the server sends 318 an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant 319 mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the 320 HIGHESTMODSEQ status data item MUST be included in the STATUS 321 response. 323 The client SHOULD NOT use FETCH attributes that implicitly set the 324 \seen flag, or that presuppose the existence of a given bodypart. 325 UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and 326 BODY/BODYSTRUCTURE may be the most useful attributes. 328 Note that if a client asks to be notified of MessageNew events, the 329 number of messages can increase at any time, and therefore the 330 client cannot refer to a specific message using the MSN/UID '*'. 332 Example in the selected mailbox: 333 S: * 444 EXISTS 334 S: * 444 FETCH (UID 9999) 336 And in another, without CONDSTORE: 337 S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) 339 5.3. MessageExpunge 341 Internet-draft August 2007 343 If the expunged message(s) is/are in the selected mailbox, the 344 server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] 345 is being used). 347 If the expunged message(s) is/are in another mailbox, the server 348 sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the 349 relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be 350 included in the STATUS response. 352 Note that if a client requests MessageExpunge, the meaning of a MSN 353 can change at any time, so the client cannot use MSNs in commands 354 anymore. For example, such a client cannot use FETCH (it must only 355 use UID FETCH). The meaning of '*' can also change when messages are 356 added or expunged. A client wishing to keep using MSNs MUST NOT 357 request the MessageExpunge event. 359 The MessageExpunge notification covers both MessageExpunge and 360 MessageExpire events from [MSGEVENT]. 362 Example in the selected mailbox, without QRESYNC: 363 S: * 444 EXPUNGE 364 The same example in the selected mailbox, with QRESYNC: 365 S: * VANISHED 5444 366 And in another: 367 S: * STATUS misc (UIDNEXT 999 MESSAGES 554) 369 5.4. QuotaExceed, QuotaWithin and QuotaChange 371 [[Alexey: I liked the following version more: If the client has 372 permission to perform GETQUOTA (defined in [RFC2087]), the server 373 sends an unsolicited QUOTA response containing the new quotas. ]] 374 The server sends an unsolicited QUOTA response containing the new 375 quotas. The server also sends an unsolicited QUOTAROOT response, so 376 that the client can correlate the affected mailbox to the quota 377 root. 379 These notifications are sent if the client has requested 380 notifications for at least one affected mailbox. 382 Example: 383 S: * QUOTAROOT INBOX "" 384 S: * QUOTA "" (STORAGE 10 512) 385 In this example the quota root named "" (see [RFC2087] for the 386 definition of quota root) governs the mailbox INBOX. Note that the 387 server may return the QUOTAROOT and the QUOTA response in any order. 389 Internet-draft August 2007 391 5.5. MailboxCreate and MailboxDelete 393 The server notifies the client by sending an unsolicited LIST 394 responses for each affected mailbox name. If the mailbox name does 395 not refer to a mailbox after the event, the \Nonexistent flag MUST 396 be included. 398 These notifications are sent if the client has requested 399 notifications for at least one affected mailbox. In the case of 400 MailboxCreate, the mailbox itself and its parent are considered to 401 be affected. In the case of MailboxDelete, all deleted mailboxes and 402 their parent(s) are considered to be affected. 404 Example of a newly created mailbox: 405 S: * LIST () "/" "NewMailbox" 407 And a deleted mailbox: 408 S: * LIST (\NoSelect) "/" "INBOX.DeletedMailbox" 410 5.6. MailboxRename 412 For each selectable mailbox renamed, the server sends an extended 413 LIST response [LISTEXT] for the new mailbox name, containing the 414 OLDNAME extended data item with the old mailbox name. When a 415 mailbox is renamed, its children are renamed too. No additional 416 MailboxRename events are sent for children in this case. When INBOX 417 is renamed, a new INBOX is assumed to be created. No MailboxCreate 418 event must be sent for INBOX in this case. 420 Example: 421 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) 423 5.7. SubscriptionChange 425 The server notifies the client by sending an unsolicited LIST 426 responses for each affected mailbox name. If and only if the mailbox 427 is subscribed after the event, the \Subscribed attribute (see 428 [LISTEXT]) is included. 430 Example: 431 S: * LIST (\Subscribed) "/" "SubscribedMailbox" 433 5.8. MailboxMetadataChange 435 The server sends an unsolicited LIST response including METADATA. If 437 Internet-draft August 2007 439 possible, only the changed metadata should be included, but if 440 necessary, all metadata must be included. 442 Example: 443 S: * LIST "/" "INBOX" (METADATA (/comment (value.priv "My 444 comment"))) 446 5.9. AdminMailbox 448 If the user has the right to perform GETACL (see [RFC4314]) after 449 the event, the server notifies the client by sending an unsolicited 450 ACL response with the mailbox' new rights. 452 If the user didn't have the right to perform GETACL, but later on 453 such right was granted, then the server MUST send the ACL response 454 to notify the client that it has access to the corresponding 455 mailbox. 457 If the user loses the right to perform GETACL as a result of an ACL 458 change, the server MUST NOT send the ACL response. Instead it MUST 459 send an extended LIST response containing the \NonExistent mailbox 460 attribute. 462 In all other cases, the server does not notify the client. 464 Example: 465 S: * ACL INBOX Fred rwipslxcetda David lrswideta 467 5.10. Notification Overflow 469 If the server is unable or unwilling to deliver as many 470 notifications as it is being asked to, it may disable notifications 471 for some or all clients. It MUST notify these clients by sending an 472 untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a 473 NOTIFY NONE command had just been received. 475 Example: 476 S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... 478 5.11. ACL Changes 480 Even if NOTIFY succeeds, it is still possible to lose access to the 481 mailboxes monitoried at a later time. If this happens, the server 482 MUST silently stop monitoring these mailboxes. If access is later 484 Internet-draft August 2007 486 granted, the server MUST restart event monitoring. 488 6. Mailbox Specification. 490 Mailboxes to be monitored can be specified in several different 491 ways. 493 If the client specifies monitoring of the same mailbox several 494 times, the first specification wins. A common example is asking for 495 events on the selected mailbox and some named mailboxes. 497 In this example, the client asks for MessageExpunge events for all 498 personal mailboxes except the selected mailbox: 499 C: a notify set (selected (MessageNew (uid flags) flagchange)) 500 (personal (MessageNew (uid flags) flagchange MessageExpunge)) 502 6.1. Selected 504 Selected refers to the mailbox selected using either SELECT or 505 EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP 506 connection is not in selected state, selected does not refer to any 507 mailbox. 509 6.2. Personal 511 Personal refers to all selectable mailboxes in the user's personal 512 namespace(s). 514 6.3. Inboxes 516 Inboxes refers to all selectable mailboxes in the user's personal 517 namespace(s) to which messages may be delivered by an MDA (see 518 [EMAIL-ARCH], particularly section 4.3.3). 520 If the IMAP server cannot easily compute this set, it MUST treat 521 "inboxes" as equivalent to "personal". 523 6.4 Subscribed 525 Subscribed refers to all mailboxes subscribed by the user. 527 If the subscription list changes, the list MUST be reevaluated. 529 Internet-draft August 2007 531 6.5 Subtree 533 Subtree is followed by a mailbox name or list of mailbox names. A 534 subtree refers to all selectable mailboxes which are subordinate to 535 the specified mailbox plus the mailbox itself. 537 [[Open Issue: Making this "all selectable mailboxes" makes it easy 538 to implement this well. The pattern can be evaluated at NOTIFY time 539 and notification information affixed to the mailboxes in RAM. Fine. 540 But what about "notify me if any mailboxes are created whose name 541 contains the letters xxx"? Not useful IMO...? (writes arnt)]] 543 6.6 Mailboxes 545 Mailboxes is followed by a mailbox name or list of mailbox names. 546 The server MUST NOT do wildcard expansion. This means there is no 547 special treatment for the LIST wildcard characters ('*' and '%') if 548 they are present in mailbox names. 550 7. Formal Syntax 552 The following syntax specification uses the Augmented Backus-Naur 553 Form (ABNF) notation as specified in [RFC4234]. [RFC3501] defines 554 the non-terminals "capability", "command-auth", "mailbox", "mailbox- 555 data", "resp-text-code" and "search-key". 557 Except as noted otherwise, all alphabetic characters are case- 558 insensitive. The use of upper or lower case characters to define 559 token strings is for editorial clarity only. Implementations MUST 560 accept these strings in a case-insensitive fashion. 562 capability =/ "X-DRAFT-W00-NOTIFY" 563 ;; [[Note to RFC Editor: change the capability 564 ;; name before publication]] 566 command-auth =/ notify 568 notify = "NOTIFY" SP 569 (notify-add / notify-set / notify-none) 571 notify-add = "ADD" [status-indicator] SP event-groups 572 ; Add (prepend) registered notification 573 ; events to the list of notification 574 ; events. Newer events override older 575 ; events. 576 [[Alexey: what about "most specific" event 578 Internet-draft August 2007 580 overriding a pattern?]] 582 notify-set = "SET" [status-indicator] SP event-groups 583 ; Replace registered notification events 584 ; with the specified list of events 586 notify-none = "NONE" 587 ; Cancel all registered notification 588 ; events. The client is not interested 589 ; in receiving any events. 591 status-indicator = SP "STATUS" 593 one-or-more-mailbox = mailbox / many-mailboxes 595 many-mailboxes = "(" mailbox *(SP mailbox) ")" 597 event-groups = event-group *(SP event-group) 599 event-group = "(" filter-mailboxes SP events ")" 601 filter-mailboxes = "selected" / "inboxes" / "personal" / 602 "subscribed" / 603 ( "subtree" SP one-or-more-mailbox ) / 604 ("mailboxes" SP one-or-more-mailbox) 606 events = ( "(" event *(SP event) ")" ) / "NONE" 607 ;; As in [MSGEVENT]. 608 ;; "NONE" means that the client does not wish 609 ;; to receive any events for the specified 610 ;; mailboxes. 612 event = message-event 613 / mailbox-event / user-event / event-ext 615 message-match-criteria = "(" search-key ")" 617 message-event = ( "MessageNew" SP 618 "(" fetch-att *(SP fetch-att) ")" 619 SP message-match-criteria ) 620 / "MessageExpunge" 621 / "FlagChange" SP message-match-criteria 622 / "AnnotationChange" SP message-match-criteria 623 ;; "MessageNew" includes "MessageAppend" from 624 ;; [MSGEVENT]. "FlagChange" is any of 625 ;; "MessageRead", "MessageTrash", "FlagsSet", 626 ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" 627 ;; includes "MessageExpire" [MSGEVENT]. 629 Internet-draft August 2007 631 mailbox-event = "MailboxCreate" / "MailboxDelete" / 632 "MailboxRename" / 633 "SubscriptionChange" / "MailboxMetadataChange" 634 / "QuotaChange" / "AdminMailbox" 635 ; "SubscriptionChange" includes 636 ; MailboxSubscribe and MailboxUnSubscribe 638 user-event = "QuotaExceed" / "QuotaWithin" 640 event-ext = atom 641 ;; For future extensions 643 oldname-extended-item = "OLDNAME" SP "(" mailbox ")" 644 ;; Extended data item (mbox-list-extended-item) 645 ;; returned in a LIST response when a mailbox is 646 ;; renamed. 647 ;; Note 1: the OLDNAME tag can be returned 648 ;; with and without surrounding quotes, as per 649 ;; mbox-list-extended-item-tag production. 651 resp-text-code =/ "NOTIFICATIONOVERFLOW" 653 8. Security considerations 655 It is very easy for a client to deny itself service using NOTIFY: 656 Asking for all events on all mailboxes may work on a small server, 657 but with a big server can swamp the client's network connection or 658 processing capability. In the worst case, the server's processing 659 could also degrade the service it offers to other clients. 661 Server authors should be aware that if a client issues requests and 662 does not listen to the resulting responses, the TCP window can 663 easily fill up, and a careless server might block. This problem 664 exists in plain IMAP, however this extension magnifies the problem. 666 This extensions makes it possible to retrieve messages immediately 667 when they are added to the mailbox. This makes it wholly impractical 668 to delete sensitive messages using programs like imapfilter. Using 669 [SIEVE] or similar is much better. 671 9. IANA considerations 673 The IANA is requested to add NOTIFY to the list of IMAP extensions, 674 http://www.iana.org/assignments/imap4-capabilities. 676 9.1. Initial LIST-EXTENDED extended data item registrations 678 Internet-draft August 2007 680 It is requested that the following entry be added to the LIST- 681 EXTENDED extended data item registry [LISTEXT]: 683 To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED 684 extended data item 686 LIST-EXTENDED extended data item tag: OLDNAME 688 LIST-EXTENDED extended data item description: The OLDNAME extended 689 data item describes the old mailbox name for the mailbox identified 690 by the LIST response. 692 Which LIST-EXTENDED option(s) (and their types) causes this extended 693 data item to be returned (if any): none 695 Published specification : RFC XXXX, Section 5.6. 697 Security considerations: none 699 Intended usage: COMMON 701 Person and email address to contact for further information: 702 Alexey Melnikov 704 Owner/Change controller: iesg@ietf.org 706 10. Acknowedgements 708 The authors gratefully acknowledge the help of Peter Coates, Dave 709 Cridland, Mark Crispin, Cyrus Daboo and Abhijit Menon-Sen. Various 710 example lines are copied from other RFCs. 712 This document builds on one published and two unpublished drafts by 713 the same authors. 715 11. Normative References 717 [RFC2087] Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997. 719 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 720 Requirement Levels", RFC 2119, Harvard University, March 721 1997. 723 [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. 725 [RFC3501] Crispin, "Internet Message Access Protocol - Version 727 Internet-draft August 2007 729 4rev1", RFC 3501, University of Washington, June 2003. 731 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 732 Specifications: ABNF", RFC 4234, Brandenburg 733 Internetworking, Demon Internet Ltd, October 2005. 735 [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", 736 RFC 4314, December 2005. 738 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 739 RFC 4466, Isode Ltd., April 2006. 741 [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE 742 Operation or Quick Flag Changes Resynchronization", RFC 743 4551, Isode Ltd., June 2006. 745 [ANNOTATE] Gellens, Daboo, "IMAP ANNOTATE Extension", draft-ietf- 746 imapext-annotate-16 (work in progress). 748 [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- 749 ietf-imapext-list-extensions-18 (work in progress), IBM, 750 September 2006. 752 [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- 753 annotatemore-11 (work in progress), Apple Computer, Inc., 754 February 2007. 756 [MSGEVENT] Newman, "Internet Message Store Events", draft-ietf- 757 lemonade-msgevent-03.txt (work in progress), Sun, July 758 2007. 760 12. Informative References 762 [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, 763 Mirapoint Inc, January 2001. 765 [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick 766 Mailbox Resynchronization", draft-ietf-lemonade- 767 reconnect-client-05.txt (work in progress), February 768 2007. 770 [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- 771 email-arch-09 (work in progress), March 2007. 773 Internet-draft August 2007 775 13. Authors' Addresses 777 Curtis King 778 Isode Ltd 779 5 Castle Business Village 780 36 Station Road 781 Hampton, Middlesex TW12 2BX 782 UK 784 Email: Curtis.King@isode.com 786 Alexey Melnikov 787 Isode Ltd 788 5 Castle Business Village 789 36 Station Road 790 Hampton, Middlesex TW12 2BX 791 UK 793 Email: Alexey.Melnikov@isode.com 795 Arnt Gulbrandsen 796 Oryx Mail Systems GmbH 797 Schweppermannstr. 8 798 D-81671 Muenchen 799 Germany 801 Email: arnt@oryx.com 803 Internet-draft August 2007 805 Intellectual Property Statement 807 The IETF takes no position regarding the validity or scope of any 808 Intellectual Property Rights or other rights that might be claimed 809 to pertain to the implementation or use of the technology described 810 in this document or the extent to which any license under such 811 rights might or might not be available; nor does it represent that 812 it has made any independent effort to identify any such rights. 813 Information on the procedures with respect to rights in RFC 814 documents can be found in BCP 78 and BCP 79. 816 Copies of IPR disclosures made to the IETF Secretariat and any 817 assurances of licenses to be made available, or the result of an 818 attempt made to obtain a general license or permission for the use 819 of such proprietary rights by implementers or users of this 820 specification can be obtained from the IETF on-line IPR repository 821 at http://www.ietf.org/ipr. 823 The IETF invites any interested party to bring to its attention any 824 copyrights, patents or patent applications, or other proprietary 825 rights that may cover technology that may be required to implement 826 this standard. Please address the information to the IETF at ietf- 827 ipr@ietf.org. 829 Full Copyright Statement 831 Copyright (C) The IETF Trust (2007). This document is subject to 832 the rights, licenses and restrictions contained in BCP 78, and 833 except as set forth therein, the authors retain all their rights. 835 This document and the information contained herein are provided on 836 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 837 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 838 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 839 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 840 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 841 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 842 FOR A PARTICULAR PURPOSE. 844 Acknowledgment 846 Funding for the RFC Editor function is currently provided by the 847 Internet Society.