summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5442.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5442.txt')
-rw-r--r--doc/rfc/rfc5442.txt843
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]
+