doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5442.txt b/doc/rfc/rfc5442.txt
new file mode 100644
index 0000000..829cb05
--- /dev/null
+++ b/doc/rfc/rfc5442.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          E. Burger
+Request for Comments: 5442                                    Consultant
+Category: Informational                                       G. Parsons
+                                                         Nortel Networks
+                                                              March 2009
+
+
+    LEMONADE Architecture - Supporting Open Mobile Alliance (OMA)
+                 Mobile Email (MEM) Using Internet Mail
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Abstract
+
+   This document specifies the architecture for mobile email, as
+   described by the Open Mobile Alliance (OMA), using Internet Mail
+   protocols.  This architecture was an important consideration for much
+   of the work of the LEMONADE (Enhancements to Internet email to
+   Support Diverse Service Environments) working group in the IETF.
+   This document also describes how the LEMONADE architecture meets
+   OMA's requirements for their Mobile Email (MEM) service.
+
+
+
+Burger & Parsons             Informational                      [Page 1]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. OMA Mobile Email (MEM) ..........................................2
+      2.1. OMA MEM Requirements .......................................2
+      2.2. OMA MEM Architecture .......................................3
+           2.2.1. OMA MEM Logical Architecture ........................3
+           2.2.2. OMA MEM Deployment Issues ...........................4
+      2.3. OMA MEM Technical Specification ............................6
+   3. IETF LEMONADE Architecture ......................................6
+      3.1. Relationship between the OMA MEM and LEMONADE Logical
+           Architectures ..............................................7
+      3.2. LEMONADE Realization of OMA MEM with
+           non-LEMONADE-Compliant Servers .............................9
+           3.2.1. LEMONADE Realization of OMA MEM with
+                  non-LEMONADE IMAP Servers ...........................9
+           3.2.2. LEMONADE Realization of OMA MEM with non-IMAP
+                  Servers ............................................10
+   4. Filters and Server-to-Client Notifications and LEMONADE ........11
+   5. Security Considerations ........................................13
+   6. Acknowledgements ...............................................13
+   7. Informative References .........................................13
+
+1.  Introduction
+
+   This document describes the architecture of OMA Mobile Email (MEM)
+   using Internet Mail protocols defined by the IETF.  The LEMONADE
+   working group has enhanced many of these protocols for use in the
+   mobile environment.  The LEMONADE profile [PROFILE] and its revision,
+   [PROFILE-bis], summarize such protocols and protocol use.  This
+   document shows how the OMA MEM Requirements document [MEM-req], OMA
+   MEM Architecture [MEM-arch], and OMA MEM Technical Specification
+   [MEM-ts] relate to the work of LEMONADE in the IETF.
+
+2.  OMA Mobile Email (MEM)
+
+   The OMA Mobile Email (MEM) sub-working group has spent some time
+   studying the requirements and architecture of mobile email.  IETF
+   LEMONADE has been liaising with them and has based much of its
+   Internet Mail enhancements on their input.  This section summarizes
+   the output of the OMA.
+
+2.1.  OMA MEM Requirements
+
+   The OMA MEM activity collected a set of use cases and derived
+   requirements for a Mobile Email (MEM) enabler.  The OMA MEM
+   Requirements document [MEM-req] summarizes this work.  Some
+   requirements relate to email protocols, some involve other OMA
+
+
+
+Burger & Parsons             Informational                      [Page 2]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+   technologies outside the scope of the IETF, and some relate to
+   implementations and normative interoperability statements for clients
+   and servers.
+
+2.2.  OMA MEM Architecture
+
+   This section introduces the OMA MEM Architecture.
+
+2.2.1.  OMA MEM Logical Architecture
+
+   The OMA MEM activity has derived a logical architecture from the
+   requirements and use cases described in [MEM-req].  A simplification
+   for illustrative purposes is shown in Figure 1, where arrows indicate
+   content flows.
+
+                       __________
+                      | Other    |
+                  +---| Mobile   |<--+
+                  |   | Enablers |   |
+                  |   |__________|   |
+                  |ME-4              |ME-3
+                 _v____           ___v____        ________
+                |      |ME-1     |        |      |        |
+                | MEM  |-------->|  MEM   |  I2  |  Email |
+                |Client|     ME-2| Server |<---->| Server |
+                |______|<--------|________|      |________|
+                                     ^
+                                     |ME-5
+                                     |
+
+               Figure 1: Basic OMA MEM Logical Architecture
+
+   Figure 1 identifies the following elements:
+
+   o  The MEM client that implements the client-side functionality of
+      the OMA Mobile Email enabler.  It is also responsible for
+      providing the mobile email user experience and interface to the
+      user and storing the email and data to be sent to the MEM server
+      when not connected.
+
+   o  The MEM server that implements the server-side functionality of
+      the OMA Mobile Email (MEM) enabler.
+
+   o  The MEM protocol between the MEM client and MEM server.  It is
+      responsible for all the in-band data exchanges that take place
+      between the MEM client and server in order to update the MEM
+
+
+
+
+
+Burger & Parsons             Informational                      [Page 3]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+      client with email server changes and the email server with changes
+      in the MEM client, and in order to send new email from the email
+      server.
+
+   o  Other OMA enablers that are needed to directly support the Mobile
+      Email enabler.  They are out of the scope of the IETF but may
+      include support for:
+
+      *  Client provisioning and management for over-the-air
+         installation of the MEM client on the device, provisioning of
+         the client settings, and revocation of client privileges.
+
+      *  Messaging enablers for out-of-band notification, where out-of-
+         band notifications that are server-to-client event exchanges
+         are not transported by the MEM protocol but via other channels.
+
+      *  Billing, charging, and so on.
+
+   OMA identifies different interfaces:
+
+   o  ME-1: MEM client interface to interact via the MEM protocol with
+      the MEM server.
+
+   o  ME-2: Corresponding interface of the MEM server.
+
+   o  ME-3: Out-of-band MEM server interfaces; for example, to support
+      generation of server-to-client notifications.
+
+   o  ME-4: Out-of-band MEM client interfaces (e.g., to receive server-
+      to-client notifications).
+
+   o  ME-5: Interface for management of MEM enabler server settings,
+      user preferences, and filters, globally and per account.
+
+   The MEM server enables an email server.  In a particular
+   implementation, the email server may be packaged with (internal to
+   it) the MEM server or be a separate component.  In such cases,
+   interfaces to the email server are out of scope of the OMA MEM
+   specifications.  In the present document, we focus on the case where
+   the backend consists of IETF IMAP and SUBMIT servers.  However, we
+   also discuss the relationship to other cases.  The I2 interface is an
+   OMA notation to designate protocol / interfaces that are not
+   specified by the MEM enabler but may be standardized elsewhere.
+
+2.2.2.  OMA MEM Deployment Issues
+
+   The OMA MEM Architecture document [MEM-arch] further identifies
+   deployment models.
+
+
+
+Burger & Parsons             Informational                      [Page 4]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+2.2.2.1.  OMA MEM Proxy
+
+   The OMA MEM Architecture document [MEM-arch] identifies OMA MEM
+   server proxies as server components that may be deployed ahead of
+   firewalls to facilitate firewall traversal.
+
+2.2.2.2.  OMA MEM Deployment Cases
+
+   OMA MEM identifies that each component (MEM client, MEM servers,
+   other enablers, and the email server) may be deployed in different
+   domains, possibly separated by firewalls and other network
+   intermediaries.  MEM proxies may be involved in front of a firewall
+   that protects the MEM server domain.
+
+   OMA MEM targets support of configurations where:
+
+   o  All components are within the same domain, such as in a mobile
+      operator.
+
+   o  The MEM client and other enablers are in the mobile operator
+      domain, there is a MEM proxy, and the MEM server and email server
+      are in the domain of the email service provider.
+
+   o  The MEM client and other enablers as well as a MEM proxy are in
+      the mobile operator domain, and the MEM server and email server
+      are in the domain of the email service provider.
+
+   o  The MEM client and other enablers are in the mobile operator
+      domain, a MEM proxy is in a third-party service provider domain,
+      and the MEM server and email server are in the domain of the email
+      service provider.
+
+   o  The MEM client, other enabler, and MEM server are in the mobile
+      operator domain, and the email server is in the domain of the
+      email service provider.
+
+   o  The MEM client and other enablers are in the mobile operator
+      domain, the MEM server is in a third-party service provider
+      domain, and the email server is in the domain of the email service
+      provider.
+
+   The email service provider can be a third-party service provider, a
+   network service provider, or an enterprise email service.
+
+
+
+
+
+
+
+
+Burger & Parsons             Informational                      [Page 5]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+2.3.  OMA MEM Technical Specification
+
+   The OMA MEM activity will conclude with a specification for a Mobile
+   Email (MEM) enabler.  The ongoing work is in the OMA MEM Technical
+   Specification [MEM-ts].  LEMONADE is a basis for the mechanism.
+   However, some additional details that are outside the scope of the
+   IETF will also be included.
+
+   OMA provides ways to perform provisioning via OMA client provisioning
+   and device management.  Other provisioning specifications are
+   available (e.g., SMS based).
+
+   OMA provides enablers to support out-of-band notification mechanisms,
+   filter specifications (such as XDM), and remote deactivate devices,
+   and to perform other non-Internet activities.
+
+3.  IETF LEMONADE Architecture
+
+   This section introduces the LEMONADE Architecture.
+
+   The IETF LEMONADE activity has derived a LEMONADE profile
+   [PROFILE-bis] with the logical architecture represented in Figure 2,
+   where arrows indicate content flows.
+
+                            ______________
+                           |              |
+                  _________| Notification |
+                 |         | Mechanism    |
+                 |         |______________|
+                 |Notif.              ^
+                 |Protocol            |
+                 |                 ___|______
+                 |                |          |                 _____
+               __v__    IMAP      | LEMONADE |      ESMTP     |     |
+              |     |<----------->| IMAP     |<---------------| MTA |
+              | MUA |-            | Store    |                |_____|
+              |_____| \           |__________|
+                       \               |
+                        \              |URLAUTH
+                         \SUBMIT       |
+                          \        ____v_____
+                           \      |          |                 _____
+                            \     | LEMONADE |      ESMTP     |     |
+                             ---->| Submit   |--------------->| MTA |
+                                  | Server   |                |_____|
+                                  |__________|
+
+                  Figure 2: LEMONADE logical architecture
+
+
+
+Burger & Parsons             Informational                      [Page 6]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+   The LEMONADE profile [PROFILE] assumes:
+
+   o  IMAP protocol [RFC3501], including LEMONADE profile extensions
+      [PROFILE].
+
+   o  SUBMIT protocol [RFC4409], including LEMONADE profile extensions.
+
+   o  LEMONADE profile compliant IMAP store connected to an MTA (Mail
+      Transfer Agent) via the ESMTP [EMAIL].
+
+   o  LEMONADE profile compliant submit server connected to an MTA,
+      often via the ESMTP.
+
+   o  Out-of-band server-to-client notifications relying on external
+      notification mechanisms (and notification protocols) that may be
+      out of the scope of the LEMONADE profile.
+
+   o  LEMONADE-aware MUA (Mail User Agent).  While use of out-of-band
+      notification is described in the LEMONADE profile, support for the
+      underlying notifications mechanisms/protocols is out of the scope
+      of the LEMONADE specifications.
+
+   Further details on the IETF email protocol stack and architecture can
+   be found in [MAIL].
+
+3.1.  Relationship between the OMA MEM and LEMONADE Logical
+      Architectures
+
+   Figure 3 illustrates the mapping of the IETF LEMONADE logical
+   architecture on the OMA MEM logical architecture.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger & Parsons             Informational                      [Page 7]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+                          _____________________
+                         | Other_Mob. Enablers |
+                         | |--------------|    |
+                  _________| Notification |    |
+                 |       | | Mechanism    |    |
+                 |       | |______________|    |
+                 |Notif. |____________^________|
+                 |Protocol      ______|__________
+            ME-4 |             |   ___|_ME-3_    |
+              ___|____         |  |          |   |         _____
+             | __v__ |  IMAP   |  | LEMONADE |   |  ESMTP |     |
+             ||     |<----------->| IMAP     |<-----------| MTA |
+             || MUA ||   ME-2a |  | Store    |   |        |_____|
+             ||_____||\ME-1    |  |__________|   |
+             | MEM   | \       |       |         |
+             | Client|  \      |       |URLAUTH  |
+             |_______|   \SUBMIT       |         |
+                          \    |   ____v_____    |
+                           \   |  |          |   |         _____
+                            \  |  | LEMONADE |   |  ESMTP |     |
+                             ---->| Submit   |----------->| MTA |
+                         ME-2b |  | Server   |   |        |_____|
+                               |  |__________|   |
+                               |MEM        Email |
+                               |Server     Server|
+                               |_________________|
+                                        ^
+                                        |ME-5
+                                        |
+
+            Figure 3: Mapping of LEMONADE Logical Architecture
+                   onto the OMA MEM Logical Architecture
+
+   As described in Section 3, the LEMONADE profile assumes LEMONADE
+   profile compliant IMAP stores and SUBMIT servers.  Because the
+   LEMONADE profile extends the IMAP store and the SUBMIT server, the
+   mobile enablement of email provided by the LEMONADE profile is
+   directly provided in these servers.  Mapping to the OMA MEM logical
+   architecture for the case considered and specified by the LEMONADE
+   profile, we logically combine the MEM server and email server.
+   However, in LEMONADE we split them logically into a distinct LEMONADE
+   message store and a LEMONADE SUBMIT server.  ME-2 consists of two
+   interfaces.  ME-2a is IMAP extended according to the LEMONADE
+   profile.  ME-2b is SUBMIT extended according to the LEMONADE profile.
+
+   The MUA is part of the MEM client.
+
+
+
+
+
+Burger & Parsons             Informational                      [Page 8]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+   The external notifications mechanism is part of the OMA enablers
+   specified by the OMA.
+
+3.2.  LEMONADE Realization of OMA MEM with non-LEMONADE-Compliant
+      Servers
+
+   The OMA MEM activity is not limited to enabling LEMONADE-compliant
+   servers.  It explicitly identifies the need to support other
+   backends.  This is, of course, outside the scope of the IETF LEMONADE
+   activity.
+
+3.2.1.  LEMONADE Realization of OMA MEM with non-LEMONADE IMAP Servers
+
+   Figure 4 illustrates the case of IMAP servers that are not LEMONADE-
+   compliant.  In such case, the I2 interface between the MEM server
+   components and the IMAP store and SUBMIT server are IMAP and SUBMIT
+   without LEMONADE extensions.
+
+   It is important to note the realizations are of a schematic nature
+   and do not dictate actual implementation.  For example, one could
+   envision collocating the LEMONADE MEM enabler server and the submit
+   server shown in Figure 4 in a single instantiation of the
+   implementation.  Likewise, we consciously label the LEMONADE MEM
+   enabler as neither an IMAP proxy nor an IMAP back-to-back user agent.
+   LEMONADE leaves the actual implementation to the developer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger & Parsons             Informational                      [Page 9]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+                 ______________
+                |              |
+       _________| Notification |
+      |         | Mechanism    |
+      |         |______________|
+      |Notif.            ^
+      |Protocol          |
+      |               ___|______          _____________
+      |              | LEMONADE |        |             |        _____
+    __v__    IMAP    | MEM      |  IMAP  |NON-LEMONADE | ESMTP |     |
+   |     |<--------->|Enabler   |<------>|IMAP         |<----->| MTA |
+   | MUA |\   ME-2a  | Server   |        |Store        |       |_____|
+   |_____| \         |__________|        |_____________|
+            \             |
+             \            |URLAUTH
+              \SUBMIT     |
+               \      ____v_____          _____________
+                \    |          |        |             |        _____
+                 \   | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP |     |
+                  -->|  MEM     |        |Submit       |       |     |
+                     | Enabler  |------->|Server       |------>| MTA |
+              ME-2b  | Server   |        |             |       |_____|
+                     |__________|        |_____________|
+
+       Figure 4: Architecture to Support Non-LEMONADE IMAP Servers
+             with a LEMONADE Realization of an OMA MEM Enabler
+
+3.2.2.  LEMONADE Realization of OMA MEM with non-IMAP Servers
+
+   Figure 5 illustrates the cases where the message store and submit
+   servers are not IMAP store or submit servers.  They may be Post
+   Office Protocol (POP3) servers or other proprietary message stores.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger & Parsons             Informational                     [Page 10]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+                 ______________
+                |              |
+       _________| Notification |
+      |         | Mechanism    |
+      |         |______________|
+      |Notif.            ^
+      |Protocol          |
+      |               ___|______          _____________
+      |              | LEMONADE |        |             |        _____
+    __v__    IMAP    | MEM      |    I2  |Proprietary  | ESMTP |     |
+   |     |<--------->|Enabler   |<------>|Message      |<----->| MTA |
+   | MUA |\   ME-2a  | Server   |        |Store        |       |_____|
+   |_____| \         |__________|        |_____________|
+            \             |
+             \            |URLAUTH
+              \SUBMIT     |
+               \      ____v_____          _____________
+                \    |          |        |             |        _____
+                 \   | LEMONADE |    I2  |Proprietary  | ESMTP |     |
+                  -->| MEM      |        |Submit       |       |     |
+                     | Enabler  |------->|Server       |------>| MTA |
+              ME-2b  | Server   |        |             |       |_____|
+                     |__________|        |_____________|
+
+    Figure 5: Architecture to Support Non-IMAP Servers with a LEMONADE
+                      Realization of OMA MEM Enabler
+
+   I2 designates proprietary adapters to the backends.
+
+4.  Filters and Server-to-Client Notifications and LEMONADE
+
+   OMA MEM Requirements [MEM-req] and Architecture [MEM-arch] emphasize
+   the need to provide mechanisms for server-to-client notifications of
+   email events and filtering.  Figure 6 illustrates how notification
+   and filtering works in the LEMONADE profile [PROFILE].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger & Parsons             Informational                     [Page 11]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+                   ______________
+                  |              |
+         _________| Notification |
+        |         | Mechanism    |
+        |         |______________|
+        |Notif.              ^
+        |Protocol -------\  _|__
+        |   ______|    ___\>|NF|____
+        |  |          |     ----    |                 _____
+      __v__|   IMAP   |__  LEMONADE |___   ESMTP   __|     |
+     |     |<-------->|VF| IMAP     |DF |<--------|AF| MTA |
+     | MUA |\   ME-2a |--  Store    |---           --|_____|
+     |_____| \        |_____________| ^
+            \_\_______________|_______|
+               \              |URLAUTH
+                \SUBMIT       |
+                 \        ____v_____
+                  \      |          |                 _____
+                   \     | LEMONADE |      ESMTP     |     |
+                    ---->| Submit   |--------------->| MTA |
+                ME-2b    | Server   |                |_____|
+                         |__________|
+
+      Figure 6: Filtering Mechanism Defined in LEMONADE Architecture
+
+   In Figure 6, we define four categories of filters:
+
+   o  AF: Administrative Filters - The email service provider usually
+      sets administrative filters.  The user typically does not
+      configure AF.  AF applies policies covering content filtering,
+      virus protection, spam filtering, etc.
+
+   o  DF: Deposit Filters - Filters that are executed on deposit of new
+      emails.  They can be defined as SIEVE filters [SIEVE].  They can
+      include vacation notices [RFC5230].  As SIEVE filters, one can
+      administer them using the SIEVE management protocol [MANAGESIEVE].
+
+   o  VF: View Filters - Filters that define which emails are visible to
+      the MUA.  View filters can be performed via IMAP using the
+      facilities described in [NOTIFICATIONS].
+
+   o  NF: Notification Filters - Filters that define for what email
+      server event an out-of-band notification is sent to the client, as
+      described in [NOTIFICATIONS].
+
+   Refer to the aforementioned references for implementation and
+   management of the respective filters.
+
+
+
+
+Burger & Parsons             Informational                     [Page 12]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+5.  Security Considerations
+
+   We note there are security risks associated with:
+
+   o  Out-of-band notifications
+
+   o  Server configuration by client
+
+   o  Client configuration by server
+
+   o  Presence of MEM proxy servers
+
+   o  Presence of MEM servers as intermediaries
+
+   o  Measures to address the need to traverse firewalls
+
+   We refer the reader to the relevant Internet Mail, IMAP, SUBMIT, and
+   Lemonade documents for how we address these issues.
+
+6.  Acknowledgements
+
+   The authors acknowledge and appreciate the work and comments of the
+   IETF LEMONADE working group and the OMA MEM working group.  We
+   extracted the contents of this document from sections of
+   [PROFILE-bis] by Stephane Maes, Alexey Melnikov, and Dave Cridland,
+   as well as sections of [NOTIFICATIONS] by Stephane Maes and Ray
+   Cromwell.
+
+7.  Informative References
+
+   [EMAIL]          Klensin, J., "Simple Mail Transfer Protocol",
+                    RFC 5321, October 2008.
+
+   [MAIL]           Crocker, D., "Internet Mail Architecture", Work
+                    in Progress, October 2008.
+
+   [MANAGESIEVE]    Melnikov, A. and T. Martin, "A Protocol for Remotely
+                    Managing Sieve Scripts", Work in Progress,
+                    January 2009.
+
+   [MEM-arch]       Open Mobile Alliance, "Mobile Email Architecture
+                    Document", OMA,
+                    http://member.openmobilealliance.org/ftp/
+                    public_documents/mwg/MEM/Permanent_documents/
+                    OMA-AD-Mobile_Email-V1_0_0-20070614-D.zip,
+                    June 2007.
+
+
+
+
+
+Burger & Parsons             Informational                     [Page 13]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+   [MEM-req]        Open Mobile Alliance, "Mobile Email Requirements
+                    Document", OMA, http://www.openmobilealliance.org/,
+                    Oct 2005.
+
+   [MEM-ts]         Open Mobile Alliance, "Mobile Email Technical
+                    Specification", OMA, Work in Progress,
+                    http://www.openmobilealliance.org/, Oct 2007.
+
+   [NOTIFICATIONS]  Gellens, R. and S. Maes, "Lemonade Notifications
+                    Architecture", Work in Progress, July 2008.
+
+   [PROFILE]        Maes, S. and A. Melnikov, "Internet Email to Support
+                    Diverse Service Environments (Lemonade) Profile",
+                    RFC 4550, June 2006.
+
+   [PROFILE-bis]    Cridland, D., Melnikov, A., and S. Maes, "The
+                    Lemonade Profile", Work in Progress, September 2008.
+
+   [RFC3501]        Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                    VERSION 4rev1", RFC 3501, March 2003.
+
+   [RFC4409]        Gellens, R. and J. Klensin, "Message Submission for
+                    Mail", RFC 4409, April 2006.
+
+   [RFC5230]        Showalter, T. and N. Freed, "Sieve Email Filtering:
+                    Vacation Extension", RFC 5230, January 2008.
+
+   [SIEVE]          Guenther, P. and T. Showalter, "Seive: An Email
+                    Filtering Language", RFC 5228, January 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger & Parsons             Informational                     [Page 14]
+
+RFC 5442                 LEMONADE Architecture                March 2009
+
+
+Authors' Addresses
+
+   Eric W. Burger
+   Consultant
+   New Hampshire
+   USA
+
+   Phone:
+   Fax:   +1 530-267-7447
+   EMail: eburger@standardstrack.com
+   URI:   http://www.standardstrack.com
+
+
+   Glenn Parsons
+   Nortel Networks
+   3500 Carling Avenue
+   Ottawa, ON  K2H 8E9
+   Canada
+
+   Phone: +1 613 763 7582
+   EMail: gparsons@nortel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger & Parsons             Informational                     [Page 15]
+