idnits 2.17.1 draft-ietf-lemonade-architecture-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 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 349 has weird spacing: '...tecture onto ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 12, 2007) is 6009 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '11' is defined on line 605, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 607, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 610, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 613, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 616, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 622, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4550 (ref. '5') (Obsoleted by RFC 5550) -- No information found for draft-ietf-lemonade-profile-bis-0x - is the name correct? ** Obsolete normative reference: RFC 3501 (ref. '7') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2821 (ref. '9') (Obsoleted by RFC 5321) == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 -- No information found for draft-newman-lemonade-msgevent-0x - is the name correct? -- No information found for draft-ietf-lemonade-convert-0x - is the name correct? -- No information found for draft-ietf-lemonade-rfc2192bis-0x - is the name correct? -- No information found for draft-crocker-email-arch-0x - is the name correct? -- No information found for draft-ietf-lemonade-reconnect-0x - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LEMONADE Working Group E. Burger 3 Internet-Draft BEA 4 Intended status: Informational G. Parsons 5 Expires: May 15, 2008 Nortel 6 November 12, 2007 8 LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using Internet 9 Mail 10 draft-ietf-lemonade-architecture-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 months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 15, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies the architecture for mobile email, as 44 described by the OMA, using Internet Mail protocols. This 45 architecture is the basis of the work of the LEMONADE WG and is a 46 guidleine for the LEMONADE Profile. 48 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 RFC 2119 [1]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. OMA Mobile Email (MEM) . . . . . . . . . . . . . . . . . . . . 5 58 2.1. OMA MEM Requirements . . . . . . . . . . . . . . . . . . . 5 59 2.2. OMA MEM Architecture . . . . . . . . . . . . . . . . . . . 5 60 2.2.1. OMA MEM logical Architecture . . . . . . . . . . . . . 5 61 2.2.2. OMA MEM Deployment Issues . . . . . . . . . . . . . . 7 62 2.3. OMA MEM Technical Specification . . . . . . . . . . . . . 8 63 3. IETF LEMONADE Architecture . . . . . . . . . . . . . . . . . . 9 64 3.1. Relationship between the OMA MEM and LEMONADE logical 65 architectures . . . . . . . . . . . . . . . . . . . . . . 10 66 3.2. LEMONADE realization of OMA MEM with non-LEMONADE 67 compliant servers . . . . . . . . . . . . . . . . . . . . 12 68 3.2.1. LEMONADE realization of OMA MEM with non-LEMONADE 69 IMAP servers . . . . . . . . . . . . . . . . . . . . . 12 70 3.2.2. LEMONADE realization of OMA MEM with non-IMAP 71 servers . . . . . . . . . . . . . . . . . . . . . . . 13 72 4. Filters and server to client notifications and LEMONADE . . . 14 73 5. Notifications objectives . . . . . . . . . . . . . . . . . . . 16 74 6. Security considerations . . . . . . . . . . . . . . . . . . . 17 75 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 76 8. Version history . . . . . . . . . . . . . . . . . . . . . . . 19 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 80 Intellectual Property and Copyright Statements . . . . . . . . . . 24 82 1. Introduction 84 This document describes the architecture of OMA mobile email (MEM) 85 using Internet Mail protocols defined by the IETF. Many of these 86 protocols have been enhanced by the LEMONADE work group for use in 87 the mobile environment and are summarized in the LEMONADE profile [5] 88 and its revision LEMONADE profile bis [6]. This document shows how 89 the OMA MEM Requirement document [3] , OMA MEM Architecture [2] and 90 OMA MEM Technical Specification [4] relate to the work of LEMONADE. 92 2. OMA Mobile Email (MEM) 94 The OMA Mobile Email (MEM) sub-working group has spent some time 95 studying the requirements and architecture of mobile email. IETF 96 LEMONADE has been liaising with them and have based much of our 97 Internet Mail enhancements based on their input. This section 98 summarizes the output of the OMA. 100 2.1. OMA MEM Requirements 102 The OMA MEM activity has collected a set of use cases and derived 103 requirements for a mobile email enabler (MEM). the resulting work is 104 summarized in OMA MEM Requirements [3]. Some requirements relates to 105 email protocols, some involve other OMA technologies outside the 106 scope of IETF and some relate to implementations and normative 107 interoperability statements for clients and servers. 109 2.2. OMA MEM Architecture 111 This section gives a brief introduction to the OMA MEM Architecture. 113 2.2.1. OMA MEM logical Architecture 115 The OMA MEM activity has derived a logical architecture from the 116 requirements and use cases described in [3]. A simplification for 117 illustrative purposes is shown inFigure 1, where arrows indicate 118 content flows. 120 __________ 121 | Other | 122 ----| Mobile |<--- 123 | | Enablers | | 124 | |__________| | 125 |ME-4 |ME-3 126 _v____ ___v____ ________ 127 | | | | | | 128 | MEM |ME-1 | MEM | I2 | Email | 129 |Client|<------->| Server |<---->| Server | 130 |______| ME-2|________| |________| 131 ^ 132 |ME-5 133 | 135 Figure 1: Basic OMA MEM logical architecture 137 It identifies the following elements: 139 o The MEM client which implements the client-side functionality of 140 the OMA Mobile Email Enabler. It is also responsible for 141 providing the mobile email user experience and interface to the 142 user and storing the email and data to be sent to the MEM server 143 when not connected. 145 o The MEM server which implements the server-side functionality of 146 the OMA Mobile Email Enabler (MEM). 148 o The MEM protocol between the MEM Client and MEM Server. It is 149 responsible for all the inband data exchanges that take place 150 between the MEM client and server in order to update the MEM 151 client with email server changes, the email server with changes in 152 the MEM client and to send new email from the email server. 154 o Other OMA enablers are needed to directly support the mobile email 155 enabler. They are out of scope of IETF but they may include 156 support for: 158 * Client provisioning and management for over the air 159 installation of the MEM client on the device, provisioning of 160 its settings and revocation 162 * Messaging enablers for outband notification, where outband 163 notifications that are server to client event exchanges not 164 transported by the MEM protocol but via other channels. 166 OMA identifies different interfaces: 168 o ME-1: MEM client interface to interact via the MEM protocol with 169 the MEM server 171 o ME-2: Corresponding interface of the MEM server 173 o ME-3: Outband MEM server interfaces (e.g. to support generation of 174 server to client notifications). 176 o ME-4: Outband MEM client interfaces (e.g. to receive server to 177 client notifications). 179 o ME-5: Interface for management of MEM enabler server settings, 180 user preferences and filters (globally and per account) 182 The MEM server enables an email server. In a particular 183 implementation, the email server may be packaged with (internal to 184 it) the MEM server or be in a separate component. In such cases, 185 interfaces to the email server are out of scope of the OMA MEM 186 specifications. In the present document, we focus on the case where 187 the backend consists of IETF IMAP and Submit servers. However, 188 relationship to other cases are also discussed. The I2 interface is 189 an OMA notation to designate protocol / interfaces that are not 190 specified by the MEM enabler but may be standardized elsewhere. 192 2.2.2. OMA MEM Deployment Issues 194 The OMA MEM Architecture document [2] further identifies deployment 195 models. 197 2.2.2.1. OMA MEM proxy 199 The OMA MEM Architecture document [2] identifies OMA MEM server 200 proxies as server components that may be deployed ahead of firewalls 201 to facilitate traversa of firewalls. 203 2.2.2.2. OMA MEM deployment cases 205 OMA MEM identifies that each component (MEM client, MEM servers, 206 Other enablers and email server) may be deployed in different 207 domains, possibly separated by firewalls and other network 208 intermediaries. MEM proxies may be involved in front of firewall 209 that protects the MEM server domain. 211 OMA MEM target support of configurations where: 213 o All components are within a same domain (Mobile operator) 215 o MEM client and other enablers are in the mobile operator domain, a 216 MEM proxy is involved and MEM server and email server are in the 217 domain of the email service provider 219 o MEM client and other enablers as well as a MEM proxy are in the 220 mobile operator domain, MEM server and email server are in the 221 domain of the email service provider 223 o MEM client and other enablers are in the mobile operator domain, a 224 MEM proxy is in a third party service provider domain and MEM 225 server and email server are in the domain of the email service 226 provider 228 o MEM client, other enabler and MEM server are in the mobile 229 operator domain and email server is in the domain of the email 230 service provider 232 o MEM client and other enablers are in the mobile operator domain, 233 MEM server is in a third party service provider domain and the 234 email server is in the domain of the email service provider 236 2.3. OMA MEM Technical Specification 238 The OMA MEM activity will conclude with a specification for a mobile 239 email enabler (MEM). The ongoing work is in OMA MEM Technical 240 Specification [4]. LEMONADE is a basis for the mechanism, however, 241 some additional details that are outside the scope of IETF will also 242 be included. 244 OMA provides ways to perform provisioning via OMA client provisioning 245 and device management. Other provisioning specifications are 246 available (e.g. SMS based). 248 OMA provides enablers to support outband notifications: the outband 249 notification mechanisms. Also, OMA XDM may be considered also for 250 outband filter changes. . 252 3. IETF LEMONADE Architecture 254 This section gives a brief introduction to the LEMONADE Architecture. 256 The IETF LEMONADE activity has derived a LEMONADE profile [5] with 257 the logical architecture represented in Figure 2, where arrows 258 indicate content flows. 260 ______________ 261 | | 262 _________| Notification | 263 | | Mechanism | 264 | |______________| 265 |Notif. ^ 266 |Protocol | 267 | ___|______ 268 | | | _____ 269 __v__ IMAP | LEMONADE | ESMTP | | 270 | |<----------->| IMAP |<---------------| MTA | 271 | MUA |- | Store | |_____| 272 |_____| \ |__________| 273 \ | 274 \ |URLAUTH 275 \SUBMIT | 276 \ ____v_____ 277 \ | | _____ 278 \ | LEMONADE | ESMTP | | 279 ---->| Submit |--------------->| MTA | 280 | Server | |_____| 281 |__________| 283 Figure 2: LEMONADE logical architecture 285 The LEMONADE profile [5] assumes: 287 o IMAP protocol [7] including LEMONADE profile extensions [5] 289 o SUBMIT protocol (SMTP [9], ...) including LEMONADE profile 290 extensions 292 o LEMONADE profile compliant IMAP store connected to MTA (Mail 293 Transfer Agent) via ESMTP [8] 295 o LEMONADE profile compliant Submit server connected to MTA via 296 ESMTP 298 o Lemonade profile message store / submit server protocols (URLAUTH) 299 (see [5]). 301 o Outband server to client notifications relying on external 302 notification mechanisms (and notification protocols) that may be 303 out of scope of the LEMONADE profile. 305 o A LEMONADE aware MUA (Mail User Agent). While use of outband 306 notification is described in the LEMONADE profile, support for the 307 underlying notifications mechanisms/protocols is out of scope of 308 the LEMONADE specifications. 310 Further details on the IETF email protcol stack and architecture can 311 be found in [16] 313 3.1. Relationship between the OMA MEM and LEMONADE logical 314 architectures 316 Figure 3 illustrates the mapping of the IETF LEMONADE logical 317 architecture on the OMA MEM logical architecture. 319 _____________________ 320 | Other_Mob. Enablers | 321 | |--------------| | 322 _________| Notification | | 323 | | | Mechanism | | 324 | | |______________| | 325 |Notif. |____________^________| 326 |Protocol ______|__________ 327 ME-4 | | ___|_ME-3_ | 328 ___|____ | | | | _____ 329 | __v__ | IMAP | | LEMONADE | | ESMTP | | 330 || |<----------->| IMAP |<-----------| MTA | 331 || MUA || ME-2a | | Store | | |_____| 332 ||_____||\ME-1 | |__________| | 333 | MEM | \ | | | 334 | Client| \ | |URLAUTH | 335 |_______| \SUBMIT | | 336 \ | ____v_____ | 337 \ | | | | _____ 338 \ | | LEMONADE | | ESMTP | | 339 ---->| Submit |----------->| MTA | 340 ME-2b | | Server | | |_____| 341 | |__________| | 342 |MEM Email | 343 |Server Server| 344 |_________________| 345 ^ 346 |ME-5 347 | 349 Figure 3: Mapping of LEMONADE logical architecture onto the OMA MEM 350 logical architecture. 352 As described in Section 3, the LEMONADE profile assumes LEMONADE 353 profile compliant IMAP stores and Submit servers. Because the 354 LEMONADE profile extends the IMAP store and the submit server, the 355 mobile enablement of email provided by the LEMONADE profile is 356 directly provided in these server. Mapped to OMA MEM logical 357 architecture, for the case considered and specified by the LEMONADE 358 profile, the MEM server and email server logically combined. They 359 are however split into distinct LEMONADE message store and LEMONADE 360 submit server. ME-2 consists of two interfaces ME-2a and ME-2b 361 associated respectively to IMAP extended according to the LEMONADE 362 profile and SUBMIT extended according to the LEMONADE profile. 364 The MUA is part of the MEM client. 366 External notifications mechanism can be part of the other OMA enabler 367 specified by OMA (or other activities). 369 3.2. LEMONADE realization of OMA MEM with non-LEMONADE compliant 370 servers 372 The OMA MEM activity is not limited to enabling Lemonade compliant 373 servers. It explicitly identifies the need to support other 374 backends. 376 3.2.1. LEMONADE realization of OMA MEM with non-LEMONADE IMAP servers 378 Figure 4 illustrates the case of IMAP servers that are not (yet) 379 LEMONADE compliant. In such case, the I2 interface between the MEM 380 server components and the IMAP store and submit server are IMAP and 381 SUBMIT. 383 ______________ 384 | | 385 _________| Notification | 386 | | Mechanism | 387 | |______________| 388 |Notif. ^ 389 |Protocol | 390 | ___|______ _____________ 391 | | LEMONADE | | | _____ 392 __v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | | 393 | |<--------->|Enabler |<------>|IMAP |<----->| MTA | 394 | MUA |\ ME-2a | Server | |Store | |_____| 395 |_____| \ |__________| |_____________| 396 \ | 397 \ |URLAUTH 398 \SUBMIT | 399 \ ____v_____ _____________ 400 \ | | | | _____ 401 \ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | | 402 -->| MEM | |Submit | | | 403 | Enabler |------->|Server |------>| MTA | 404 ME-2b | Server | | | |_____| 405 |__________| |_____________| 407 Figure 4: Architecture to support non-LEMONADE IMAP servers with a 408 LEMONADE realization of OMA MEM enabler. 410 3.2.2. LEMONADE realization of OMA MEM with non-IMAP servers 412 Figure 5 illustrates the cases where the message store and submit 413 servers are not IMAP store or submit servers. They may be POP3 414 servers or other proprietary message stores. 416 ______________ 417 | | 418 _________| Notification | 419 | | Mechanism | 420 | |______________| 421 |Notif. ^ 422 |Protocol | 423 | ___|______ _____________ 424 | | LEMONADE | | | _____ 425 __v__ IMAP | MEM | I2 |Proprietary | ESMTP | | 426 | |<--------->|Enabler |<------>|Message |<----->| MTA | 427 | MUA |\ ME-2a | Server | |Store | |_____| 428 |_____| \ |__________| |_____________| 429 \ | 430 \ |URLAUTH 431 \SUBMIT | 432 \ ____v_____ _____________ 433 \ | | | | _____ 434 \ | LEMONADE | I2 |Proprietary | ESMTP | | 435 -->| MEM | |Submit | | | 436 | Enabler |------->|Server |------>| MTA | 437 ME-2b | Server | | | |_____| 438 |__________| |_____________| 440 Figure 5: Architecture to support non-IMAP servers with a LEMONADE 441 realization of OMA MEM enabler. 443 I2 designates proprietary adapters to the backends. They may invoved 444 functions performed in the message stores or submit server as well as 445 in the MEM enabler server. 447 4. Filters and server to client notifications and LEMONADE 449 OMA MEM RD [3] and AD [2] emphasize the need to provide mechanisms 450 for server to client notifications of email events and filtering. 451 Figure 6 illustrates how notification and filterings are introduced 452 in LEMONADE profile [5]. 454 ______________ 455 | | 456 _________| Notification | 457 | | Mechanism | 458 | |______________| 459 |Notif. ^ 460 |Protocol -------\ _|_ 461 | ______| ___\>|NF|____ 462 | | | ---- | _____ 463 __v__| IMAP |__ LEMONADE |___ ESMTP __| | 464 | |<-------->|VF| IMAP |DF |<--------|AF| MTA | 465 | MUA |\ ME-2a |-- Store |-^- --|_____| 466 |_____| \ |_____________| | 467 \_\_______________|_______| 468 \ |URLAUTH 469 \SUBMIT | 470 \ ____v_____ 471 \ | | _____ 472 \ | LEMONADE | ESMTP | | 473 ---->| Submit |--------------->| MTA | 474 ME-2b | Server | |_____| 475 |__________| 477 Figure 6: Filtering mechanism defined in LEMONADE architecture 479 In Figure 6, four categories of filters are defined: 481 o AF: Administrative Filters - Set up by email service provider. AF 482 are typically not configured by the user and set to apply policies 483 content filtering, virus protection, spam filtering etc... 485 o DF: Deposit Filters - Filters that are executed on deposit of new 486 emails. They can be defined as SIEVE filters [10]. They can 487 include vacation notices. 489 o VF: View Filters - Filters that define which emails are visible to 490 the MUA. View filters can be performed via IMAP using the 491 facilities described in [6]. 493 o NF: Notification Filters - Filters that define for what email 494 server event an outband notification is sent to the client, as 495 described in [6]. 497 The filters are manageable from the MUA: 499 o NF and DF: via SIEVE management protocol 501 5. Notifications objectives 503 According to these analyses, there is a need to support: # Mechanisms 504 for event-based (server to client) synchronization: * Defines the 505 relationship between notification mechanisms and the IMAP4 protocol - 506 To minimize the latency observed for email events on the email server 507 to be reflected in the email client. - To avoid unnecessary polling 508 and requests from the e-mail clients: . To reduce the total amount 509 of data to be exchanged between email server and client, e.g. by 510 allowing the email client to select which messages to synchronize and 511 how to synchronize. . To reduce the amount of transactions. * Needs 512 to cope with possible lost or delayed notifications * Support in-band 513 (within IMAP band) and out-band notifications (Exchanged via other 514 servers / enablers). - Specified in ways that are network transport 515 independent but may contain some bindings to particular notification 516 channels (e.g. SMS binary, WAP Push, SIP Notification, ...) - When 517 the email client is connected to the email server, only inband 518 notifications is expected take place * Defines notification payload 519 for inband and outband mechanisms. # Server-side filtering to decide 520 which messages will be accessible by the email client. * Filtering 521 results into the following logical types: - Type A: Messages filtered 522 out and not accessible by the email client (no notification, no 523 header access, no access) - Type B: Messages that are accessible by 524 the mobile e-mail enabler client but no outband notification takes 525 place. Inband notification might however take place if email client 526 is already connected to email server. - Type C: Messages that are 527 accessible by the e-mail client for which notifications (outband or 528 inband) are always sent to the email client. # Notions of Filters: * 529 View filters: Filters that determine which email messages are of type 530 B and C or A * Notification filters: Filters that determine which 531 email messages are of type C or B * Event filters: Filters that 532 determines what events are to be notified to the client # Mechanisms 533 to allow the user to update the filters from the email client # 534 Mechanisms to allow configuration and exchange of settings between 535 the client and the server in band or outband: - Server to client: 536 e.g. server ID, account name, policies, ... - Client to server: e.g. 537 rules filters vacation notices, notification channel, ... 539 6. Security considerations 541 This specification provides no security measures beyond those in the 542 referenced Internet Mail and LEMONADE documents. 544 We note however that there are security risks associated to: 546 o Outband notifications 548 o Server configuration by client 550 o Client configuration by server 552 o Presence of MEM proxy servers 554 o Presence of MEM servers as intermediaries 556 o Measures to addess the need to traverse firewalls 558 7. IANA considerations 560 No specific IANA considerations have been identified that are not 561 covered by the different drafts and RFCs included in the realization 562 described in this document. 564 8. Version history 566 Version 0: This document was extracted from sections of 567 draft-ietf-lemonade-profile-bis-05.txt and 568 draft-ietf-lemonade-notifications-04.txt. 570 9. Acknowledgements 572 The authors acknowledge and appreciate the work and comments of the 573 IETF LEMONADE working group and the OMA MEM working group. 575 10. References 577 [1] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirements Levels", RFC 2119, BCP 14, March 1997. 580 [2] "Mobile Email Architecture Document", 581 OMA http://www.openmobilealliance.org/, June 2007. 583 [3] "Mobile Email RequirementS Document", 584 OMA http://www.openmobilealliance.org/, Oct 2005. 586 [4] "Mobile Email Technical Specification", OMA (Work in Progress), 587 http://www.openmobilealliance.org/, Oct 2007. 589 [5] Maes, S. and A. Melnikov, "LEMONADE profile", RFC 4550. 591 [6] Maes, S. and A. Melnikov, "LEMONADE profile bis", 592 draft-ietf-lemonade-profile-bis-0x (work in progress). 594 [7] Crispin, M., "IMAP4, Internet Message Access Protocol Version 4 595 rev1", RFC 3501, March 2003. 597 [8] Klensin, J., "SMTP Service Extensions", RFC 1861, 598 November 1995. 600 [9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 601 April 2001. 603 [10] "SIEVE", Internet Draft draft-ietf-sieve-3028bis-12. 605 [11] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 607 [12] Newman, C., "Internet Message Store Events", 608 draft-newman-lemonade-msgevent-0x (work in progress). 610 [13] "Open Mobile Alliance Email Notification Version 1.0", 611 OMA http://www.openmobilealliance.org/, August 2002. 613 [14] Maes, S. and et Al., "CONVERT", draft-ietf-lemonade-convert-0x 614 (work in progress). 616 [15] Melnikov, A. and et Al., "IMAP URL Scheme", 617 draft-ietf-lemonade-rfc2192bis-0x (work in progress). 619 [16] Crocker, D., "Internet Mail Architecture", 620 draft-crocker-email-arch-0x (work in progress). 622 [17] Melnikov, A. and et Al., "IMAP4 extension for quick reconnect", 623 draft-ietf-lemonade-reconnect-0x (work in progress). 625 Authors' Addresses 627 Eric Burger 628 BEA Systems, Inc. 629 Boston, MA 630 USA 632 Phone: +1 781 993 7437 633 Email: eburger@bea.com 635 Glenn Parsons 636 Nortel Networks 637 3500 Carling Avenue 638 Ottawa, ON K2H 8E9 639 Canada 641 Phone: +1 613 763 7582 642 Email: gparsons@nortel.com 644 Full Copyright Statement 646 Copyright (C) The IETF Trust (2007). 648 This document is subject to the rights, licenses and restrictions 649 contained in BCP 78, and except as set forth therein, the authors 650 retain all their rights. 652 This document and the information contained herein are provided on an 653 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 654 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 655 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 656 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 657 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 658 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 Intellectual Property 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at 682 ietf-ipr@ietf.org. 684 Acknowledgment 686 Funding for the RFC Editor function is provided by the IETF 687 Administrative Support Activity (IASA).