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