[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5550

LEMONADE Working Group                                           S. Maes
Internet-Draft                                                    Oracle
Expires: August 2, 2006                                      A. Melnikov
                                                                   Isode
                                                             D. Cridland
                                                     Details To Be Added
                                                        January 29, 2006


                          LEMONADE profile bis
                 draft-ietf-lemonade-profile-bis-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes LEMONADE profile bis.  It contains pointers
   or mention to all the features that are normatively part of LEMONADE
   profile bis.

   It is based on a combination of the content of LEMONADE profile [4]



Maes, et al.             Expires August 2, 2006                 [Page 1]

Internet-Draft            LEMONADE profile bis              January 2006


   and the OMA MEM realization internet draft [21], initially considered
   for internet draft publication as information or standard track by
   LEMONADE.  It reflects the agreed content for LEMONADE profile bis
   after the Beijing LEMONADE Intermediate face to face meeting.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  LEMONADE Profile . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  OMA MEM Requirement document . . . . . . . . . . . . . . . . .  5
   4.  OMA MEM Architecture . . . . . . . . . . . . . . . . . . . . .  6
   5.  OMA MEM Deployment Issues  . . . . . . . . . . . . . . . . . .  7
   6.  OMA MEM proxy  . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  IETF LEMONADE Architecture . . . . . . . . . . . . . . . . . .  9
   8.  LEMONADE profile bis logical architecture  . . . . . . . . . . 11
     8.1.  Relationship between the OMA MEM and LEMONADE logical
           architectures  . . . . . . . . . . . . . . . . . . . . . . 11
     8.2.  LEMONADE realization of OMA MEM with non-LEMONADE
           compliant servers  . . . . . . . . . . . . . . . . . . . . 12
       8.2.1.  LEMONADE realization of OMA MEM with non-LEMONADE
               enhanced IMAP servers  . . . . . . . . . . . . . . . . 12
       8.2.2.  LEMONADE realization of OMA MEM with non-IMAP
               servers  . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Filters and server to client notifications and LEMONADE  . . . 15
   10. LEMONADE Profile bis features  . . . . . . . . . . . . . . . . 17
   11. Security considerations  . . . . . . . . . . . . . . . . . . . 19
   12. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 20
   13. Future work  . . . . . . . . . . . . . . . . . . . . . . . . . 21
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25












Maes, et al.             Expires August 2, 2006                 [Page 2]

Internet-Draft            LEMONADE profile bis              January 2006


1.  Introduction

   This document describes LEMONADE profile bis.  It contains pointers
   or mention to all the features that are normatively part of LEMONADE
   profile bis.

   It is based on LEMONADE profile [4] with extensions to provide the
   support to a realization of OMA mobile email enabler (MEM) using
   Internet Mail protocols defined by the IETF.  Many of these protocols
   have been enhanced by the LEMONADE work group for use in the mobile
   environment and are summarized in the LEMONADE profile [4].

   This document also supports the requirements captured in OMA MEM
   Requirement document [3] and mechanisms of the OMA MEM Architecture
   [2], following the LEMONADE point of view described in the  OMA MEM
   realization internet draft [21].

   This document contains the current view of the work.  It refers to
   stable specifications and work in progress.  As the work progress, it
   is expected that this document will evolve and be updated
   accordingly.

   <Editor's note: As a result some of the statements about some
   specification may not yet supported by the references.  When it is
   the case, these specifications are expected to be be updated.>

   <Editor's note: Caveats to be removed and / or updated when work
   stabilizes.>

   Also, it is to be noted that this document solely describes
   normatively the LEMONADE profile bis.  It discusses LEMONADE
   understanding of the work in progress at OMA MEM ([3] and [2] but
   does not provide a normative reading of these documents.  Readers
   MUST refer to the open mobiel alliance web site for normative
   references on the Mobile Email Enabler (OMA MEM).  LEMONADE assumes
   that the LEMONADE profile bis can be used as basis for an OMA
   technical specification of a realization based on LEMONADE of the OMA
   MEM enabler.













Maes, et al.             Expires August 2, 2006                 [Page 3]

Internet-Draft            LEMONADE profile bis              January 2006


2.  LEMONADE Profile

   LEMONADE profile bis incorporates normatively the LEMONADE profile
   [4].

   <Editor's note: The LEMONADE profile is currently included by
   reference.  As it stabilizes as RFC, the text will be explicitly
   included and changes to the text will be explicitly made inline.>











































Maes, et al.             Expires August 2, 2006                 [Page 4]

Internet-Draft            LEMONADE profile bis              January 2006


3.  OMA MEM Requirement document

   The OMA MEM activity has collected a set of use cases and derived
   requirements for a mobile email enabler (MEM). the resulting work is
   summarized in OMA MEM Requirement document [3].  Some requirements
   relates to email protocols, some involve other OMA technologies
   outside the scope of IETF and some relate to implementations and
   normative interoperability statements for clients and servers.











































Maes, et al.             Expires August 2, 2006                 [Page 5]

Internet-Draft            LEMONADE profile bis              January 2006


4.  OMA MEM Architecture

   The OMA MEM activity has derived a logical architecture from the
   requirements and use cases described in [3].  The logical
   architecture, its elements and interfaces and the notations that it
   uses can be found in [2].













































Maes, et al.             Expires August 2, 2006                 [Page 6]

Internet-Draft            LEMONADE profile bis              January 2006


5.  OMA MEM Deployment Issues

   The OMA MEM Architecture document [2] further identifies deployment
   models.

   Certain of these deployment models are not what IETF has
   conventionally modeled.  They require special attention to end-to-end
   security aspects and may warrant introduction of additional security
   measures (e.g. object level encryption).










































Maes, et al.             Expires August 2, 2006                 [Page 7]

Internet-Draft            LEMONADE profile bis              January 2006


6.  OMA MEM proxy

   The OMA MEM Architecture document [2] identifies OMA MEM server
   proxies as server components that may be deployed ahead of firewalls
   to facilitate traversal of firewalls.

   Both IMAP and SMTP generally are compatible with proxies between the
   client and the server.  Such proxies may disrupt end-to-end
   encryption, with the transport-level encryption ending at the proxy
   and re-generating from the proxy to the server.  Again this may
   require additional security measures like object level encryption.








































Maes, et al.             Expires August 2, 2006                 [Page 8]

Internet-Draft            LEMONADE profile bis              January 2006


7.  IETF LEMONADE Architecture

   This section gives a brief introduction to the LEMONADE Architecture.

   The IETF LEMONADE activity has derived a LEMONADE profile [4] with
   the logical architecture represented in Figure 1, 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 1: LEMONADE logical architecture

   The LEMONADE profile bis assumes:

   o  IMAP protocol [5] including LEMONADE profile extensions [4]

   o  SUBMIT protocol (SMTP [7], ...) including LEMONADE profile
      extensions

   o  LEMONADE profile compliant IMAP store connected to MTA (Mail
      Transfer Agent) via ESMTP [6]

   o  LEMONADE profile compliant Submit server connected to MTA via
      ESMTP

   o  Lemonade profile ptotocols between message store and submit server
      (URLAUTH) (see [4]).



Maes, et al.             Expires August 2, 2006                 [Page 9]

Internet-Draft            LEMONADE profile bis              January 2006


   o  Outband server to client notifications relying on external
      notification mechanisms (and notification protocols) that may be
      out of scope of the LEMONADE profile bis.

   o  A LEMONADE aware MUA (Mail User Agent).  While use of outband
      notification is described in the LEMONADE profile bis, support for
      the underlying notifications mechanisms/protocols is out of scope
      of the LEMONADE specifications.

   Further details on the IETF email protocol stack and architecture can
   be found in [8]

   Note that in Figure 1 the IMAP server and Submit server are
   represented connected to MTAs (Mail Transfer Agents) via ESMTP [6].
   This is not really essential.  It could as well be X.400 so long as
   the message in the store is in the internet form.

   OMA MEM identifies other functionalities.  These are considered as
   out of scope of the LEMONADE work and will need to be specified by
   OMA MEM.































Maes, et al.             Expires August 2, 2006                [Page 10]

Internet-Draft            LEMONADE profile bis              January 2006


8.  LEMONADE profile bis logical architecture

   This section details the LEMONADE profile bis logical architecture.
   Thsi architecture is also expected to support the OMA MEM logical
   Architecture.

8.1.  Relationship between the OMA MEM and LEMONADE logical
      architectures

   Figure 2 illustrates the mapping of the IETF LEMONADE logical
   architecture on the OMA MEM logical architecture.


                          _____________________
                         | 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 2: Mapping of LEMONADE profile bis logical architecture  onto
   the OMA MEM logical architecture.

   As described in Section 7, the LEMONADE profile bis assumes LEMONADE
   profile bis compliant IMAP stores and Submit servers.  Because the



Maes, et al.             Expires August 2, 2006                [Page 11]

Internet-Draft            LEMONADE profile bis              January 2006


   LEMONADE profile bis extends the IMAP store and the submit server,
   the mobile enablement of email provided by the LEMONADE profile bis
   is directly provided in these server.  Mapped to OMA MEM logical
   architecture, for the case considered and specified by the LEMONADE
   profile bis, the MEM server and email server logically combined.
   They are however split into distinct LEMONADE message store and
   LEMONADE submit server.  The OMA MEM interfaces ME-2 ([2]) consists
   of two interfaces ME-2a and ME-2b associated respectively to IMAP
   extended according to the LEMONADE profile bis and SUBMIT extended
   according to the LEMONADE profile bis.

   The MUA is part of the MEM client.

   External notifications mechanism can be part of the other OMA enabler
   specified by OMA (or other activities).

8.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.

8.2.1.  LEMONADE realization of OMA MEM with non-LEMONADE enhanced IMAP
        servers

   Figure 3 illustrates the case of IMAP servers that are not (yet)
   LEMONADE compliant / enhanced with LEMONADE.  In such case, the I2
   interface between the MEM server components and the IMAP store and
   submit server are IMAP and SUBMIT.





















Maes, et al.             Expires August 2, 2006                [Page 12]

Internet-Draft            LEMONADE profile bis              January 2006


                 ______________
                |              |
       _________| 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 3: Architecture to support non-LEMONADE enhanced IMAP  servers
   with a LEMONADE realization of OMA MEM enabler.

   In Figure 3, the server may be a separate proxy.

8.2.2.  LEMONADE realization of OMA MEM with non-IMAP servers

   <Editor's note: This section and the previous section and figures may
   be combined in a future release of this draft.>

   Figure 4 illustrates the cases where the message store and submit
   servers are not IMAP store or submit servers.  They may be POP3
   servers or other proprietary message stores.













Maes, et al.             Expires August 2, 2006                [Page 13]

Internet-Draft            LEMONADE profile bis              January 2006


                 ______________
                |              |
       _________| 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 4: Architecture to support non-IMAP servers with a LEMONADE
   realization of OMA MEM enabler.

   I2 designates proprietary adapters to the backends.  They may invoved
   functions performed in the message stores or submit server as well as
   in the MEM enabler server.

   In Figure 4, the server may be a separate proxy.


















Maes, et al.             Expires August 2, 2006                [Page 14]

Internet-Draft            LEMONADE profile bis              January 2006


9.  Filters and server to client notifications and LEMONADE

   OMA MEM RD [3] and AD [2] emphasize the need to provide mechanisms
   for server to client notifications of email events and filtering.
   Figure 5 illustrates how notification and filterings are introduced
   in LEMONADE profile bis.



                   ______________
                  |              |
         _________| 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 5: Filtering mechanism defined in LEMONADE architecture

   In Figure 5, four categories of filters are defined:

   o  AF: Administrative Filters - Set up by email service provider.  AF
      are typically not configured by the user and set to apply policies
      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 [9].  They can
      include vacation notices.

   o  VF: View Filters - Filters that define which emails are visible to
      the MUA.  View filters can be defined as virtual folders [10] as
      described in [10] and [23].



Maes, et al.             Expires August 2, 2006                [Page 15]

Internet-Draft            LEMONADE profile bis              January 2006


   o  NF: Notification Filters - Filters that define for what email
      server event an outband notification is sent to the client.

   The filters are manageable from the MUA:

   o  NF and DF: via SIEVE management protocol <Editor's note: Still to
      be defined>

   o  VF: via virtual folder mechanisms as discussed in [10] and [23]










































Maes, et al.             Expires August 2, 2006                [Page 16]

Internet-Draft            LEMONADE profile bis              January 2006


10.  LEMONADE Profile bis features

   <Editor's note: The LEMONADE profile bis features will be detailed in
   this section (except for changes that affect inline the the LEMONADE
   profile [4] - these will be made inline in the original LEMONADE
   profile [4] text (See Section 2).>

   The LEMONADE Profile bis provides normative support for the technical
   features identified within scope of IETF LEMONADE work in the OMA MEM
   realization internet draft [21].

   <Editor's note: This text will be updated when all features are
   appropriately addressed. [21] will be maintained as a working
   document to remain synchronized with the LEMONADE prfile bis to
   ensure supporting all committed aspects.>

   The following is a list of features that will be normatively
   described: <Editor's note: The features are currently introduced by
   reference to documents that are work in progress and may still be
   individual drafts.  They are expected to become WG drafts and RFCs.
   References will be updated and text provided to explain the normative
   usage in LEMONADE profile bis.>

   o  LEMONADE profile [4] features, evolved to include capabilities to
      edit on MUA and send differences to server even for address
      fields..

   o  Notifications (server to client) as discussed in [23].

   o  Filters as discussed in [23], [10], [9] and [22].  Events that can
      be bound to notifications are described in [13].  Filter remote
      management are discussed in [23], [10] and [26]

   o  Virtual folders as discussed in [10]

   o  Media conversion as discussed in [15].  Streamed media conversion
      is still under consideration.

   o  Quick reconnect as discussed in [17]

   o  Compression as discussed in [24]

   o  Intermediaries as discussed in [20] to become a best practice
      document (draft-ietf-lemonade-deployments).  It is also addressed
      by informational track draft [18]

   o  Object level encryption and Proxies are still under discussion.
      We await proposals.  An example of object level encryption is



Maes, et al.             Expires August 2, 2006                [Page 17]

Internet-Draft            LEMONADE profile bis              January 2006


      provided in [25] as XENCRYPT. [23] further discusses the use for
      notification encryption.

   o  Message recall within SUBMIT domain.















































Maes, et al.             Expires August 2, 2006                [Page 18]

Internet-Draft            LEMONADE profile bis              January 2006


11.  Security considerations

   This specification provides no security measures beyond those in the
   referenced Internet Mail and LEMONADE documents.

   We note however the security risks associated to:

   o  Outband notifications

   o  Server configuration by client

   o  Client configuration by server

   o  Presence of proxy servers

   o  Presence of servers as intermediaries

   o  In general the deployment models considered by OMA MEM that are
      not conventional IETF deployment models.

   o  Measures to address the need to traverse firewalls and mobile
      network intermediaries.





























Maes, et al.             Expires August 2, 2006                [Page 19]

Internet-Draft            LEMONADE profile bis              January 2006


12.  IANA considerations

   No specific IANA considerations have been identified yet that are not
   covered by the different drafts and RFCs included in the realization
   described in this document.














































Maes, et al.             Expires August 2, 2006                [Page 20]

Internet-Draft            LEMONADE profile bis              January 2006


13.  Future work

   The different drafts and RFCs referenced in this document must be
   completed.  Some require initial proposals (e.g. object level
   encryption, proxies, recall and conversion of streamed media).

   Text will be updated as described in editor's notes












































Maes, et al.             Expires August 2, 2006                [Page 21]

Internet-Draft            LEMONADE profile bis              January 2006


14.  Acknowledgements

   The author acknowledges and appreciates the work and comments of the
   IETF LEMONADE working group and the OMA MEM working group.

   This text was partially co-authored with G. Vaudreuil (Lucent) and
   Eric Burger (Excel) and reviewed in detail by them as well as by Fan
   Xiaohui (China Mobile - CMCC).

15.  References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate
         Requirements Levels", RFC 2119, BCP 14, March 1997.

   [2]   "Mobile Email Architecture Document", OMA (Work in Progress),
         http://www.openmobilealliance.org/, October 2005.

   [3]   "Mobile Email RequirementS Document", OMA http://
         www.openmobilealliance.org/release_program/docs/RD/
         OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005.

   [4]   Maes, S. and A. Melnikov, "LEMONADE profile",
         draft-ietf-lemonade-profile-0x (work in progress).

   [5]   Crispin, M., "IMAP4, Internet Message Access Protocol Version 4
         rev1", RFC 3501, March 2003.

   [6]   Klensin, J., "SMTP Service Extensions", RFC 1861,
         November 1995.

   [7]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.

   [8]   Crocker, D., "Internet Mail Architecture",
         draft-crocker-email-arch-0x (work in progress).

   [9]   "SIEVE WG",  http://www.ietf.org/html.charters/sieve-
         charter.html.

   [10]  Maes, S. and et Al., "Persistent Search Extensions and Virtual
         Folder to the IMAP Protocol", draft-maes-lemonade-vfolder-0x,
         to become draft-ietf-lemonade-vfolder-0x and
         draft-ietf-lemonade-search-while-0x (work in progress).

   [11]  Maes, S. and et Al., "Server to Client Notifications and
         Filtering",
         draft-maes-lemonade-notifications-server-to-client-0x (work in
         progress).



Maes, et al.             Expires August 2, 2006                [Page 22]

Internet-Draft            LEMONADE profile bis              January 2006


   [12]  Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.

   [13]  Newman, C., "Internet Message Store Events",
         draft-newman-lemonade-msgevent-0x (work in progress).

   [14]  "Open Mobile Alliance Email Notification Version 1.0",
         OMA http://www.openmobilealliance.org/tech/docs/EmailNot/OMA-
         Push-EMN-V1_0-20020830-C.pdf, August 2002.

   [15]  Maes, S. and et Al., "CONVERT", draft-ietf-lemonade-convert-0x
         (work in progress).

   [16]  Melnikov, A. and et Al., "IMAP URL Scheme",
         draft-ietf-lemonade-rfc2192bis-0x (work in progress).

   [17]  Melnikov, A. and et Al., "IMAP4 extension for quick reconnect",
         draft-ietf-lemonade-reconnect-0x (work in progress).

   [18]  Maes, S. and et Al., "Lemonade HTTP Binding",
         draft-maes-lemonade-http-binding-0x to target informational RFC
         (work in progress).

   [19]  Freed, N., "Behavior of and Requirements for Internet
         Firewalls", RFC 2979, October 2000.

   [20]  Maes, S., "Lemonade and the challenges of Intermediaries",
         draft-smaes-lemonade-intermediary-challenges-0x (work in
         progress).

   [21]  Maes, S. and G. Parsons, "Realization of OMA Mobile Email (MEM)
         Architecture using Internet Mail",
         draft-ietf-lemonade-oma-mem-realization-0x (work in progress).

   [22]  Leiba, B., "Support for Sieve in Internet Message Access
         Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-0x (work in
         progress).

   [23]  Maes, S., "Lemonade notifications and filters",
         draft-ietf-lemonade-notifications-0x (work in progress).

   [24]  Maes, S. and R. Cromwell, "LZIP", draft-maes-lemonade-lzip-0x
         to become draft-ietf-lemonade-compress-0x (work in progress).

   [25]  Maes, S. and et Al., "Push Extensions to the IMAP Protocol
         (P-IMAP)", draft-maes-lemonade-p-imap-xx (work in progress).

   [26]  Martin, T. and A. melnikov, "A Protocol for Remotely Managing
         Sieve Scripts", draft-martin-managesieve-0x (work in progress).



Maes, et al.             Expires August 2, 2006                [Page 23]

Internet-Draft            LEMONADE profile bis              January 2006


Authors' Addresses

   Stephane H. Maes
   Oracle
   MS 4op634, 500 Oracle Parkway
   Redwood Shores, CA  94539
   USA

   Phone: +1-203-300-7786
   Email: stephane.maes@oracle.com


   Alexey Melnikov
   Isode
   5 Castle Business Village, 36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: alexey.melnikov@isode.com


   Dave Cridland
   Details To Be Added

   Email: dave@cridland.net


























Maes, et al.             Expires August 2, 2006                [Page 24]

Internet-Draft            LEMONADE profile bis              January 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Maes, et al.             Expires August 2, 2006                [Page 25]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/