idnits 2.17.1 draft-ietf-lemonade-notifications-10.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 733. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 715. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) == Outdated reference: A later version (-12) exists of draft-ietf-lemonade-profile-bis-08 -- Obsolete informational reference (is this intentional?): RFC 4551 (ref. 'CONDSTORE') (Obsoleted by RFC 7162) == Outdated reference: A later version (-06) exists of draft-ietf-lemonade-imap-sieve-05 == Outdated reference: A later version (-12) exists of draft-martin-managesieve-08 == Outdated reference: A later version (-07) exists of draft-ietf-lemonade-msgevent-05 == Outdated reference: A later version (-07) exists of draft-ietf-lemonade-imap-notify-05 == Outdated reference: A later version (-04) exists of draft-ietf-lemonade-architecture-01 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Lemonade Notifications Architecture R. Gellens (Editor) 3 Document: draft-ietf-lemonade-notifications-10.txt Qualcomm 4 Expires: January 2009 July 8, 2008 5 Intended Status: Informational 7 Lemonade Notifications Architecture 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt The list of 28 Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The IETF Trust (2008). All Rights Reserved. 35 Abstract 37 This document discusses how to provide notification and filtering 38 mechanisms to mail stores to meet Lemonade goals. 40 This document also discusses the use of server to server 41 notifications, and how server to server notifications fit into an 42 architecture which provides server to client notifications. 44 Gellens [Page 1] Expires January 2009 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 48 1.1. Conventions Used in this Document . . . . . . . . . . . 2 49 2. Notifications logical architecture and LEMONADE Profile . . 2 50 3. Event-based synchronization . . . . . . . . . . . . . . . 4 51 4. Push Email . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 5. Server-to-Server Notifications Rationale . . . . . . . . . 5 53 5.1. Notifications Discussion . . . . . . . . . . . . . . . . 6 54 5.2. Server to Server Notifications Scope . . . . . . . . . 7 55 5.3. Basic Operation . . . . . . . . . . . . . . . . . . . . 8 56 5.4. Event order . . . . . . . . . . . . . . . . . . . . . . 10 57 5.5. Reliability . . . . . . . . . . . . . . . . . . . . . . 10 58 6. Security Considerations . . . . . . . . . . . . . . . . . 10 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 60 8. Normative References . . . . . . . . . . . . . . . . . . . 11 61 9. Informative References . . . . . . . . . . . . . . . . . . . 11 62 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . 12 63 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 64 Appendix A: Changes from Previous Versions . . . . . . . . . 13 65 Intellectual Property Statement . . . . . . . . . . . . . . . 16 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 67 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 69 1. Introduction 71 The lemonade work [LEMONADE-PROFILE] identified a need to provide 72 notification and filtering mechanisms for use with IMAP [IMAP]. 74 In addition, external groups which make use of IETF work also 75 expressed such requirements (see, for example, [OMA-LEMONADE-ARCH]; 76 OMA requirements for within-IMAP ("inband") and out-of-IMAP 77 ("outband") server to client notifications are listed in 78 [OMA-ME-RD]). 80 1.1. Conventions Used in this Document 82 Within this document, the terms "Lemonade Profile" and "Lemonade" 83 generally refer to the revised Lemonade Profile document 84 [LEMONADE-PROFILE]. 86 Gellens [Page 2] Expires January 2009 87 2. Notifications logical architecture and LEMONADE Profile 89 The target logical architecture for the LEMONADE Profile is 90 described in the revised Lemonade Profile document 91 [LEMONADE-PROFILE]. 93 Figure 1 illustrates how notification and filtering fit in the 94 context of Lemonade. 96 +--------------+ 97 | |.... 98 +=========| Notification |.NF. 99 ! | Server |.... 100 ! | |^ ^ 101 ! +--------------+! ! 102 Notif-! ! ! 103 ications! Filter Protocol ! ! 104 Protocol! !======================! ! 105 ! ! ! 106 ! ! Filter Protocol ! 107 ! !=====================\.... +---------+ 108 ! ! +-----------.NF.---+ | | 109 V ! | .... | | MTA | 110 +-----+ IMAP |.... | LMTP/ |.... |<==SMTP 111 | | <======> |.VF. IMAP ....| SMTP |.AF. | 112 | MUA |\ ME-2a |.... Store .DF.|<=======|.... | 113 | | \ | ....| | | 114 +-----+ \ +------------------+ +---------+ 115 \ ! 116 \ !URLAUTH 117 SUBMIT\ ! 118 \ +----v-----+ 119 \ | | +-----+ 120 \ | LEMONADE | SMTP | |==>SMTP 121 ===>| Submit |===============>| MTA | 122 ME-2b | Server | | | 123 | | +-----+ 124 +----------+ 126 Figure 1: Filtering mechanism defined in 127 Lemonade Profile architecture. 129 In Figure 1, four categories of filters are defined: 131 1. AF: Administrative Filters: Created and maintained by mail 132 admin. AF are typically not configured by the user and are used to 133 apply policies, content filtering, virus protection, spam filtering, 134 etc. 136 Gellens [Page 3] Expires January 2009 137 2. DF: Deposit Filters: Executed on deposit of new mail. Can be 138 defined as SIEVE filters [SIEVE]. 140 3. VF: View Filters: Define which messages are important to a 141 client. May be implemented as pseudo-virtual mailboxes [CONTEXT]. 142 Clients may use this to restrict which messages they synchronize. 144 4. NF: Notification Filters: Determines when out-of-IMAP 145 ("outband") notifications are sent to the client. These filters can 146 be implemented either in the message store, or in a separate 147 notifications engine. 149 Note that when implementing DF or NF using Sieve, the 'enotify' 150 [SIEVE-NOTIFY] and likely the 'variables' [SIEVE-VARIABLES] Sieve 151 extensions might be needed. 153 The filters are manageable by the client as follows: 155 * NF and DF: When internal to the mail store, these are 156 typically implemented using Sieve and hence a Sieve management 157 protocol is used for client modifications. See [MANAGE-SIEVE] for 158 more information. Per-mailbox notifications might be implemented 159 using a combination of a primary Sieve script for notifications on 160 delivery into a mailbox (e.g., FILEINTO) and a per-mailbox Sieve 161 script such as [IMAP-SIEVE] for transfers into a mailbox. When the 162 NF is within a notification server, it is out of scope of Lemonade. 164 * VF: via pseudo-virtual mailboxes as defined in [CONTEXT]. 166 In Figure 1, the NF are shown both as part of the mail store (for 167 example, using Sieve) and as an external notification server. 168 Either approach can be used. 170 Gellens [Page 4] Expires January 2009 171 3. Event-based synchronization 173 +----------------+ +---------------+ +------------+ 174 | COMPLETE | (VF) | VIEW | (NF) | PUSH | 175 | REPOSITORY | View | REPOSITORY |Notification| REPOSITORY | 176 | |Filters| | Filters | | 177 | all email | | email to be | | important | 178 | in the account |=======|synched by the |=========| email / | 179 | | | mobile client | | | events | 180 | | | (CONTEXT) | | | | 181 +----------------+ +---------------+ | +------------+ 182 | | 183 IDLE / | 184 NOTIFY Out-of-IMAP 185 | Notifications 186 | | 187 V V 189 Figure 2: Filters and Repositories 191 For in-IMAP ("inband") notifications, the MUA (client) issues IDLE 192 [IDLE], or the successor extension command NOTIFY [NOTIFY]; the 193 LEMONADE IMAP server sends notifications as unsolicited responses to 194 the client. 196 Out-of-IMAP ("outband") notifications are messages sent to the user 197 or client not through IMAP. When directed at the user, they are 198 human-consumable and intended to alert the user. When directed at 199 the client, they are machine-consumable and may be acted upon by the 200 receiver in various ways, for example, fetching data from the mail 201 store or resynchronizing one or more mailboxes, updating internal 202 state information, and alerting the user. 204 4. Push Email 206 A good user experience of "push email" requires that when 207 "interesting" events occur in the mail store, the client is informed 208 so that it can connect and resynchronize. The Lemonade Profile 209 [LEMONADE-PROFILE] contains more information, especially in the 210 Section titled "External Notifications". 212 5. Server-to-Server Notifications Rationale 214 With server to server notifications, a mail system generates event 215 notifications. These notifications describe mailbox state change 216 events such as arrival of a new message, mailbox full, and so forth. 218 Gellens [Page 5] Expires January 2009 219 See [MSGEVENT] for a list of such events. 221 These state change notifications are sent to a notification system, 222 which may generate alerts or notifications for delivery to one or 223 more clients or the user. 225 Server to server notifications allow the mail system to generate end 226 user or client notifications without needing to keep track of 227 notification settings for users or clients; the notification system 228 maintains notification preferences for clients and users. 230 Using server to server notifications, the mail system can provide 231 the end user with a unified notification experience (the same look 232 and feel for all messaging systems' accounts, such as email and 233 voice mail), while allowing smooth integration of additional 234 messaging systems. 236 5.1. Notifications Discussion 238 The POP3 and IMAP4 Internet mail protocols allow mail clients to 239 access and manipulate electronic mail messages on mail systems. By 240 definition and scope, these protocols do not provide off-line 241 methods to notify an end user when the mailbox state changes. Nor 242 does either protocol define a way to aggregate the status within the 243 end user's various mailboxes. 245 The desire for this functionality is obvious. For example, from the 246 very early days of electronic mail, various notifications mechanisms 247 have been used, including login shell checks, and simple hacks such 248 as [BIFF]. 250 To provide an end user with unified notifications and one 251 centralized message-waiting indication (MWI), notification 252 mechanisms are needed which aggregate the information of all the 253 events occurring on the end user's different messaging systems. 255 Server to server notifications allow the messaging system to send 256 state change events to the notification system when something 257 happens in or to an end user's mailbox. 259 Notification systems can be broadly grouped into three general 260 architectures: external smart clients, intrinsic notification, and 261 separate notification mechanisms. 263 External smart clients are agents independent of the mail system 264 that periodically check mailbox state (or receive notifications, for 265 example via IMAP IDLE) and inform the user or the user's mail 266 client. Many such systems have been used over the years, including 268 Gellens [Page 6] Expires January 2009 269 login shells that check the user's mail spool, laptop/desktop tiny 270 clients that periodically poll the user's mail servers, etc. 272 Intrinsic notification is any facility within a mail system that 273 generates notifications, for example the server component of [BIFF], 274 or, for more modern systems, the recent Sieve extensions for 275 notifications [SIEVE-NOTIFY]. 277 Separate notification systems decouple the state change event 278 notification from the end-user or client notification, allowing a 279 mail system to do the former, and specialized systems (such as those 280 which handle presence) to be responsible for the latter. This 281 separation is architecturally cleaner, since the mail system only 282 needs to support one additional protocol (for communication to the 283 notification system) instead of multiple notification delivery 284 protocols, and does not need to keep track of which clients and 285 which users are interested in which events. It also allows 286 notifications to be generated for any service, not just electronic 287 mail. However, it requires a new service (the notification system) 288 and the mail system needs to support an additional protocol (to 289 communicate with the notification system). 291 In addition to any external notification mechanisms, Sieve can be 292 used for notifications [SIEVE-NOTIFY]. Since many mail systems 293 already provide Sieve support, it is often a fairly easy and quick 294 deployment option to provide a useful form of notifications. 296 5.2. Server to Server Notifications Scope 298 For the purposes of the Lemonade work, the scope of server to server 299 notifications is limited to communications between the mail system 300 and the notification system (the third architectural type described 301 in Section 5.1). Communication between the notification system and 302 the end user or devices (which might use SMS, WAP Push, instant 303 messaging, etc.) is out of scope. Likewise, the scope generally 304 presumes a security relationship between the mail system and the 305 notification system. Thus the security relationship then becomes 306 the responsibility of the notification system. However, the 307 specifics of security, trust relationships, and related issues 308 depend on the specifics of both server to server notifications and 309 notification systems. 311 Gellens [Page 7] Expires January 2009 312 Figure 3 shows the context of server to server notifications; only 313 the left side is in scope for Lemonade: 315 +--------+ +--------+ 316 New | |_ | SMS | 317 Message | Mail | \ |Gateway | 318 -------> |Server 1| \ __| | 319 +--------+ \ / +--------+ 320 ^ \ / 321 | \ / ^ 322 | \ +--------------+ / | +--------+ 323 +--------+ | \ | | / | | MWI | 324 Read | Voice | | -| Notification |/ | |Gateway | 325 Message | Mail |-------->| Server |------->| | 326 -------> | Server | | ^ __| |\ ^ | +--------+ 327 +--------+ | | / |(out of scope)| \ | | 328 | |/ | | \| | 329 | / ^ +--------------+ ^ \ | 330 |/| | \ | |\| 331 +--------+ / | | \ | | \ +--------+ 332 Mailbox | | /| | | \| | |\ | Wap | 333 Full | Mail |/ | | | ^ \ | | \| Push | 334 -------> |Server 2| | | | | |\| | |Gateway | 335 +--------+ | | | | | \ | +--------+ 336 | | | | | |\| 337 | | | | | | \ 338 | | | | | | |\ +--------+ 339 | | | | | | | \| IM | 340 | | | | | | | |Gateway | 341 | | | | | | | | | 342 | | | | | | | +--------+ 343 | | | | | | | 344 | | | | | | | 345 Server to OTHER 346 Server PROTOCOLS 347 Notifications (out of scope) 348 (in scope) 350 Figure 3: Scope of server to server notifications 352 5.3. Basic Operation 354 The mail system sends state change event notifications to the 355 notification system (which in turn might notify a client or end 356 user) for events that occur in the end user's mailboxes. Each such 357 notification, referring to a single mailbox event, is called a state 358 change event. 360 Gellens [Page 8] Expires January 2009 361 The state change event contains data regarding the mailbox event 362 which has occurred. The state change event describes the change, 363 but normally does not specify how or if the end user or client is 364 notified; this allows the end user and client notification 365 preferences to be maintained only within the notification server. 367 From the Lemonade viewpoint, out-of-IMAP (outband) notifications are 368 usually desired only when the client is not connected to the IMAP 369 server (since inband notifications are used when there is an IMAP 370 connection). Thus, it is helpful for the mail system to be able to 371 inform the notification system when the user logs in or out, and 372 which client is used (when this information is available). 374 When Sieve is used, the Sieve engine might have access to this 375 information. 377 A message is generated by the message store as a result of a state 378 change event. This message may be delivered to the end user, a 379 client, or to an external notification server which might deliver an 380 equivalent message to the user or to a client. 382 Within the context of Lemonade profile (Figure 1), the event is 383 filtered by NF. That is, the Notification Filters logically 384 determine which state change events cause notification to the user 385 or client. 387 Notifications allow for a rich end user experience. This might 388 include conveying mailbox status, new message attributes, etc., to 389 the user or client independent of the client's connection to the 390 mail store. 392 Notifications also allow for different Message Waiting Indicator 393 (MWI) behaviors (e.g., turn MWI indication off after all the 394 messages in all the end user's mailboxes have been read, should such 395 an unlikely thing occur in the real world). 397 The payload of a notification might include a URL referring to the 398 message which caused the event, possibly using URLAUTH [URLAUTH]. 400 As state change events occur in the mail store, they are filtered, 401 which is to say matched against client or user preferences. As a 402 result, a notification may or may not be generated for delivery to 403 the user or client. 405 In the most general case, the mail system sends bulk state change 406 events to an external notification server, and it is the 407 notification server that filters the events by matching against the 408 user's or client's preferences. 410 Gellens [Page 9] Expires January 2009 411 In the most mail-specific case, the mail system performs the 412 filtering itself, for example using Sieve. 414 5.4. Event order 416 For Lemonade profile, the event order is generally not important. 417 By including information such as the modification sequence 418 identifier (called a modseq or mod-sequence) [CONDSTORE] in 419 notifications, the receiving client can quickly and easily determine 420 if it has already processed the triggering event (for example, if a 421 notification arrives out of order, or if the client has 422 resynchronized). 424 For generic server to server notifications, the order is likely to 425 matter and the mail system needs to provide notifications to the 426 notification system in the order that they occur. 428 5.5. Reliability 430 For the Lemonade profile, lost or delayed notifications to the 431 client are tolerated. A client can resynchronize its state 432 (including that reported by any missing events) when it next 433 connects to the server. 435 For generic server to server notifications, it is assumed that the 436 data in a state change event is important, and therefore a high 437 level of reliability is needed between the mail system and any 438 external notification systems. 440 6. Security Considerations 442 Notification content (payload) needs to be protected against 443 eavesdropping and alteration when it contains specific information 444 from messages, such as the sender. 446 Even when the content is trivial and does not contain 447 privacy-sensitive information, guarding against denial of service 448 attacks may require authentication or verification of the 449 notification sender. 451 Protocols which manipulate filters need mechanisms to protect 452 against modification by as well as disclosure to unauthorized 453 entities. For example, a malicious entity might try to delete 454 notifications the user wants, or try to flood the target device with 455 notifications to incur usage charges, or prevent normal use. In 456 addition, the filters themselves might contain sensitive information 458 Gellens [Page 10] Expires January 2009 459 or reveal interpersonal or inter-organizational relationships, as 460 well as e-mail addresses. 462 7. IANA Considerations 464 None. 466 8. Normative References 468 [IMAP] Crispin, M. "IMAP4, Internet Message Access Protocol Version 469 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 471 [LEMONADE-PROFILE] D. Cridland, A. Melnikov, S. Maes, "LEMONADE 472 profile bis", draft-ietf-lemonade-profile-bis-08.txt, (work in 473 progress). 475 9. Informative References 477 [BIFF] Gellens, R., "Simple New Mail Notification", RFC 4146, August 478 2005. 480 [CONTEXT] D. Cridland, C. King, "Contexts for IMAP4", 481 draft-cridland-imap-context-05.txt (work in progress). 483 [CONDSTORE] Melnikov, A., Hole, S., RFC 4551, June 2006. 485 [IMAP-SIEVE] Leiba, B., "Support for Sieve in Internet Message 486 Access Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-05.txt 487 (work in progress). 489 [MANAGE-SIEVE] Martin, T. and A. Melnikov, "A Protocol for Remotely 490 Managing Sieve Scripts", draft-martin-managesieve-08.txt, (work in 491 progress). 493 [MSGEVENT] Gellens, R., Newman, C., "Internet Message Store Events", 494 draft-ietf-lemonade-msgevent-05.txt, (work in progress). 496 [IDLE] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997. 498 [NOTIFY] C. King, A. Melnikov, A. Gulbrandsen, "The IMAP NOTIFY 499 Extension", draft-ietf-lemonade-imap-notify-05.txt, (work in 500 progress). 502 [OMA-LEMONADE-ARCH], E. Burger, G. Parsons, "LEMONADE Architecture 503 -- Supporting OMA Mobile Email (MEM) using Internet Mail", 504 draft-ietf-lemonade-architecture-01.txt, (work in progress). 506 Gellens [Page 11] Expires January 2009 508 [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, 509 (Work in progress). http://www.openmobilealliance.org/ 511 [SIEVE] P. Guenther, T. Showalter, "Sieve: Sieve: An Email 512 Filtering Language", RFC 5228, January 2008. 514 [SIEVE-NOTIFY] A. Melnikov, B. Leiba, W. Segmuller, T. Martin, 515 "SIEVE Email Filtering: Extension for Notifications", 516 draft-ietf-sieve-notify-12.txt, (work in progress). 518 [SIEVE-VARIABLES] Homme, K., "Sieve Email Filtering: Variables 519 Extension", RFC 5229, January 2008. 521 [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access 522 Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006. 524 10. Contributors 526 The original (and longer and more detailed) version of this document 527 was authored by Stephane H. Maes and Ray Cromwell of Oracle 528 Corporation. 530 The current and original authors want to thank all who have 531 contributed key insight in notifications and filtering and have 532 authored specifications or drafts used in this document. 534 The current and original authors want to thank the authors of the 535 original work on Server To Server Notification Protocol Requirements 536 (draft-ietf-lemonade- notify-s2s-00) some of whose material has been 537 incorporated in the present document, and in particular, Gev 538 Decktor. 540 11. Authors' Addresses 542 Randall Gellens 543 QUALCOMM Incorporated 544 5775 Morehouse Drive 545 San Diego, CA 92121 546 rg+ietf@qualcomm.com 548 Stephane H. Maes 549 Oracle Corporation 550 500 Oracle Parkway 551 M/S 4op634 552 Redwood Shores, CA 94065 553 USA 554 Phone: +1-650-607-6296 556 Gellens [Page 12] Expires January 2009 557 Email: stephane.maes@oracle.com 559 Ray Cromwell 560 Oracle Corporation 561 500 Oracle Parkway 562 Redwood Shores, CA 94065 563 USA 565 Gellens [Page 13] Expires January 2009 566 Appendix A: Changes from Previous Versions 568 THIS SECTION TO BE REMOVED BY THE RFC EDITOR PRIOR TO PUBLICATION. 570 version -10: 571 o Rewording of IMAP-SIEVE reference in Section 2. 573 version -09: 574 o Reworded and moved sieve-variables reference in Section 2. 575 o Reworded imap-sieve reference in Section 2. 576 o Changed reference to Profile-Bis from Section 4.1.2 to "External 577 Notifications". 578 o Reworded mention of security relationship responsibility in 579 Section 5.2. 581 version -08: 582 o Removed mention of vacation notices in Section 2, Figure 1 583 (description of DF category of filters) since vacation notices, 584 while often a function of delivery filters, are out of scope of 585 lemonade. 586 o Improved text in Section 5 and 5.1. 587 o Renamed Sections 5 and 5.1. 588 o Deleted old section 5.4.1 (Generic Case). 589 o Reworded Section 1 (Introduction). 590 o Added Section 1.1 to explain that "Lemonade Profile" here refers 591 to profile-bis. 592 o Deleted reference to original (non-bis) Profile. 593 o Improved wording in Section 3. 594 o Split latter part of Section 5.1 into new Section 5.2 (Scope). 595 o Combined Sections 5.3 (Notification payloads) and 5.4 (Server to 596 server notification protocol details), as the sections no longer 597 discuss separate topics, nor were they any longer related to 598 their titles. 599 o Updated references to current versions. 601 version -07: 602 o Fixed bugs in NF arrows in Figure 1. 603 o Edited text following Figure 1 to try and make it more clear 604 that NF can be either in the mail store (using Sieve) or in the 605 notifications engine (using mechanisms out of scope to 606 Lemonade). 607 o Changed Acknowledgments section to Contributors to better 608 reflect Stephan's and Ray's text. 609 o Tweaked text in Section 5. 610 o Added mention of filter protection to Security Considerations. 612 version -06: 613 o Added pointer to profile-bis 5.4.2 ("External Notifications") 614 o Cleaned up references, split into Normative/Informative 616 Gellens [Page 14] Expires January 2009 617 o Reworded old Section 4 ("Event-based synchronization"), added 618 NOTIFY and IDLE references 619 o Deleted Section 1 ("Conventions Used in this Document") as none 620 of it applied any longer. 621 o Reworded and reworked old Section 5 ("Server to server 622 notifications considerations") and its subsections and added 623 reference to msgevents draft and RFC 4146. 624 o Changed "notification request" to "state change event". 625 o Added "within-IMAP" and "out-of-IMAP" to most occurrences of 626 "inband" and "outband". 627 o Added mention of user login/logout as a state change that can be 628 used to trigger outband notifications. 629 o Redid Figure 1 to make it easier to understand, and also to show 630 that NF might be within the mail store (Sieve) or in an external 631 notification mechanism. 632 o Deleted section 5.3 ("Server to server terminology"). 633 o Deleted reference to 634 draft-ietf-lemonade-notification-protocol-xx. 635 o Major changes to section 5.4 ("Notification payloads") and 636 section 5.5 ("Server to server notification protocol details"). 637 o Deleted section 5.5.2 ("Abstracted notification protocol"), 638 section 5.5.3 ("Exception Handling"), and section 5.6 ("Server 639 to server complementary information"). 640 o Rewrote section 5.7 ("Event orders") and added reference to RFC 641 4551. 642 o Rewrote section 5.8 ("Reliability"). 643 o Added references to sieve-notify, IMAP NOTIFY, IMAP, and others. 644 o Deleted many, many references. 645 o Updated references. 646 o Corrected references. 647 o Split references into normative and informative. 648 o Added reference to draft-ietf-lemonade-architecture-00.txt. 649 o Rewrote Introduction. 650 o Changed draft name from "... and Filters" to "... 651 Architecture". 653 version -05: 654 o Significant deletion of sections, per 655 www1.ietf.org/mail-archive/web/lemonade/current/msg03936.html 657 version -04: 658 o Update dates, slight reformatting, add editor's note for 659 References 661 version -03: 662 o Updated examples to use new METADATA syntax 663 o Drop CLEARIDLE and reference A. Melnikov's IMAP-EVENTS 664 o XEMN notification format extended to with event and view 665 attributes 667 Gellens [Page 15] Expires January 2009 668 o View filter is a work in progress. Several proposals are being 669 discussed, so the draft has been revised to try and capture high 670 level requirements (e.g. out of band notifications must be able 671 to identify which view an event occurred for) 672 o Added notification protocol details and reference 674 version -02: 675 o LPROVISION/LGETPREFS/LSETPREFS removed in favor of mailbox 676 annotations 677 o Updated inband notification section to include discussion of 678 CLEARIDLE and MSGEVENTS 679 o EMN payload clarified for both wakeup and extended formats. 680 o Some reference clean-up 681 o Add server to server notifications based on the expired draft 682 draft-ietf-lemonade-notify-s2s-00. 684 version -01: 685 o Move SMS / WAP examples to an informative appendix. 686 o Restrict the exchange of keys via LPROVISION to secure 687 exchanges. 688 o Differentiate ANNOTATE from LPROVISION on that basis. 690 versin -00: 691 o Initial release 693 Intellectual Property Statement 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed 697 to pertain to the implementation or use of the technology described 698 in this document or the extent to which any license under such 699 rights might or might not be available; nor does it represent that 700 it has made any independent effort to identify any such rights. 701 Information on the procedures with respect to rights in RFC 702 documents can be found in BCP 78 and BCP 79. 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use 707 of such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository 709 at http://www.ietf.org/ipr. 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org. 717 Gellens [Page 16] Expires January 2009 718 Full Copyright Statement 720 Copyright (C) The IETF Trust (2008). 722 This document is subject to the rights, licenses and restrictions 723 contained in BCP 78, and except as set forth therein, the authors 724 retain all their rights. 726 This document and the information contained herein are provided on 727 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 728 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 729 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 730 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 731 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 732 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 733 FOR A PARTICULAR PURPOSE. 735 Acknowledgement 737 Funding for the RFC Editor function is currently provided by the 738 Internet Society. 740 Gellens [Page 17] Expires January 2009