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

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

LEMONADE Working Group                                      S. Maes, Ed.
Internet-Draft                                                    Oracle
Expires: November 29, 2006                              A. Melnikov, Ed.
                                                           Isode Limited
                                                        D. Cridland, Ed.
                                                   Inventure Systems Ltd
                                                            May 28, 2006


                          LEMONADE profile bis
                 draft-ietf-lemonade-profile-bis-02.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 November 29, 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.

   This document describes a profile (a set of required extensions,



Maes, et al.            Expires November 29, 2006               [Page 1]

Internet-Draft            LEMONADE profile bis                  May 2006


   restrictions and usage modes) of the IMAP and mail submission
   protocols.  This profile allows clients (especially those that are
   constrained in memory, bandwidth, processing power, or other areas)
   to efficiently use IMAP and Submission to access and submit mail.
   This includes the ability to forward received mail without needing to
   download and upload the mail, to optimize submission and to
   efficiently resynchronize in case of loss of connectivity with the
   server.

   The Lemonade profile relies upon extensions to IMAP and Mail
   Submission protocols; specifically URLAUTH and CATENATE IMAP protocol
   ([RFC3501]) extensions and BURL extension to the SUBMIT protocol
   (SUBMIT).

   It provides also extensions to provide support for realizations of
   OMA mobile email enabler (MEM) ([MEM-req] and [MEM-arch]) using
   Internet Mail protocols defined by the IETF.

Conventions used in this document

   In examples, "M:", "I:" and "S:" indicate lines sent by the client
   messaging user agent, IMAP e-mail server and SMTP submit server
   respectively.

   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 [RFC2119].

   All examples in this document are optimized for Lemonade use and
   might not represent examples of proper protocol usage for a general
   use Submit/IMAP client.  In particular examples assume that Lemonade
   Submit and IMAP servers support all Lemonade extensions described in
   this document, so they don't show how to deal with absence of an
   extension.

















Maes, et al.            Expires November 29, 2006               [Page 2]

Internet-Draft            LEMONADE profile bis                  May 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Forward without download . . . . . . . . . . . . . . . . . . .  7
     2.1.  Motivations  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Message Sending Overview . . . . . . . . . . . . . . . . .  7
     2.3.  Traditional Strategy . . . . . . . . . . . . . . . . . . .  7
     2.4.  Step by step description . . . . . . . . . . . . . . . . .  8
       2.4.1.  Message assembly using IMAP CATENATE extension . . . .  9
       2.4.2.  Message assembly using SMTP CHUNKING and BURL
               extensions . . . . . . . . . . . . . . . . . . . . . . 13
     2.5.  Normative statements related to forward without
           download . . . . . . . . . . . . . . . . . . . . . . . . . 18
     2.6.  Security Considerations for pawn-tickets.  . . . . . . . . 18
     2.7.  The fcc problem  . . . . . . . . . . . . . . . . . . . . . 18
     2.8.  Registration of $Forwarded IMAP keyword  . . . . . . . . . 19
   3.  Message Submission . . . . . . . . . . . . . . . . . . . . . . 20
     3.1.  Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 20
     3.2.  DSN Support  . . . . . . . . . . . . . . . . . . . . . . . 20
     3.3.  Message size declaration . . . . . . . . . . . . . . . . . 20
     3.4.  Enhanced status code Support . . . . . . . . . . . . . . . 20
     3.5.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.  Message Store  . . . . . . . . . . . . . . . . . . . . . . . . 21
     4.1.  Quick resynchronization  . . . . . . . . . . . . . . . . . 21
     4.2.  Message part handling  . . . . . . . . . . . . . . . . . . 21
     4.3.  Compression  . . . . . . . . . . . . . . . . . . . . . . . 21
     4.4.  Out of band notifications  . . . . . . . . . . . . . . . . 22
     4.5.  Virtual Folders  . . . . . . . . . . . . . . . . . . . . . 22
     4.6.  Additional IMAP extensions . . . . . . . . . . . . . . . . 22
   5.  Summary of the required IMAP and SMTP extensions . . . . . . . 24
   6.  OMA MEM Requirement document . . . . . . . . . . . . . . . . . 26
   7.  OMA MEM Architecture . . . . . . . . . . . . . . . . . . . . . 27
   8.  OMA MEM Deployment Issues  . . . . . . . . . . . . . . . . . . 28
   9.  OMA MEM proxy  . . . . . . . . . . . . . . . . . . . . . . . . 29
   10. IETF LEMONADE Architecture . . . . . . . . . . . . . . . . . . 30
   11. LEMONADE profile bis logical architecture  . . . . . . . . . . 32
     11.1. Relationship between the OMA MEM and LEMONADE logical
           architectures  . . . . . . . . . . . . . . . . . . . . . . 32
     11.2. LEMONADE realization of OMA MEM with non-LEMONADE
           compliant servers  . . . . . . . . . . . . . . . . . . . . 33
       11.2.1. LEMONADE realization of OMA MEM with non-LEMONADE
               enhanced IMAP servers  . . . . . . . . . . . . . . . . 33
       11.2.2. LEMONADE realization of OMA MEM with non-IMAP
               servers  . . . . . . . . . . . . . . . . . . . . . . . 34
   12. Filters and server to client notifications and LEMONADE  . . . 36
   13. LEMONADE Profile bis features  . . . . . . . . . . . . . . . . 38
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 40
     14.1. Confidentiality Protection of Submitted Messages . . . . . 40



Maes, et al.            Expires November 29, 2006               [Page 3]

Internet-Draft            LEMONADE profile bis                  May 2006


     14.2. TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
     14.3. Additional extensions and deployment models  . . . . . . . 41
   15. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 42
   16. Future work  . . . . . . . . . . . . . . . . . . . . . . . . . 43
   17. Version history  . . . . . . . . . . . . . . . . . . . . . . . 44
   18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
   Appendix A.  Streaming attachments . . . . . . . . . . . . . . . . 47
   19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
     19.1. Normative References . . . . . . . . . . . . . . . . . . . 49
     19.2. Informative References . . . . . . . . . . . . . . . . . . 53
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
   Intellectual Property and Copyright Statements . . . . . . . . . . 55







































Maes, et al.            Expires November 29, 2006               [Page 4]

Internet-Draft            LEMONADE profile bis                  May 2006


1.  Introduction

   Lemonade provides enhancements to Internet email to support diverse
   service environments.

   It is based on LEMONADE profile [profile].

   This document describes the lemonade profile-bis that includes:

   o  "Forward without download" that describes exchanges between
      Lemonade clients and servers to allow to submit new email messages
      incorporating content which resides on locations external to the
      client.

   o  Quick mailbox resynchronization using [CONDSTORE].

   o  Several IMAP and SMTP extensions that allow saving bandwidth
      and/or number of round trips required to send/receive data.

   o  Extensions to provide support to realizations 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 [profile].

   This document also supports the requirements captured in OMA MEM
   Requirement document [MEM-req] and mechanisms of the OMA MEM
   Architecture [MEM-arch], following the LEMONADE point of view
   described in the  OMA MEM realization internet draft
   [OMAMEMrealization].

   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 be supported by the references.  When that
   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 ([MEM-req] and [MEM-
   arch] but does not provide a normative reading of these documents.
   Readers MUST refer to the Open Mobile Alliance web site for normative



Maes, et al.            Expires November 29, 2006               [Page 5]

Internet-Draft            LEMONADE profile bis                  May 2006


   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 November 29, 2006               [Page 6]

Internet-Draft            LEMONADE profile bis                  May 2006


2.  Forward without download

2.1.  Motivations

   The advent of client/server email using the [RFC3501], [RFC2821] and
   [Submit] protocols has changed what formerly were local disk
   operations to become repetitive network data transmissions.

   Lemonade "forward without download" makes use of the [BURL] SUBMIT
   extension to enable access to external sources during the submission
   of a message.  In combination with the IMAP [URLAUTH] extension,
   inclusion of message parts or even entire messages from the IMAP mail
   store is possible with a minimal trust relationship between the IMAP
   and SMTP SUBMIT servers.

   Lemonade "forward without download" has the advantage of maintaining
   one submission protocol, and thus avoids the risk of having multiple
   parallel and possibly divergent mechanisms for submission.  The
   client can use Submit/SMTP [Submit] extensions without these being
   added to IMAP.  Furthermore, by keeping the details of message
   submission in the SMTP SUBMIT server, Lemonade "forward without
   download" can work with other message retrieval protocols such as
   POP, NNTP, or whatever else may be designed in the future.

2.2.  Message Sending Overview

   The act of sending an email message can be thought of as involving
   multiple steps: initiation of a new draft, draft editing, message
   assembly, and message submission.

   Initiation of a new draft and draft editing takes place in the MUA.
   Frequently, users choose to save more complex messages on an
   [RFC3501] server (via the APPEND command with the \Draft flag) for
   later recall by the MUA and resumption of the editing process.

   Message assembly is the process of producing a complete message from
   the final revision of the draft and external sources.  At assembly
   time, external data is retrieved and inserted in the message.

   Message submission is the process of inserting the assembled message
   into the [RFC2821] infrastructure, typically using the [Submit]
   protocol.

2.3.  Traditional Strategy

   Traditionally, messages are initiated, edited, and assembled entirely
   within an MUA, although drafts may be saved to an [RFC3501] server
   and later retrieved from the server.  The completed text is then



Maes, et al.            Expires November 29, 2006               [Page 7]

Internet-Draft            LEMONADE profile bis                  May 2006


   transmitted to an MSA for delivery.

   There is often no clear boundary between the editing and assembly
   process.  If a message is forwarded, its content is often retrieved
   immediately and inserted into the message text.  Similarly, when
   external content is inserted or attached, the content is usually
   retrieved immediately and made part of the draft.

   As a consequence, each save of a draft and subsequent retrieve of the
   draft transmits that entire (possibly large) content, as does message
   submission.

   In the past, this was not much of a problem, because drafts, external
   data, and the message submission mechanism were typically located on
   the same system as the MUA.  The most common problem was running out
   of disk quota.

2.4.  Step by step description

   The model distinguishes between a Messaging User Agent (MUA), an
   IMAPv4Rev1 Server ([RFC3501]) and a SMTP submit server ([Submit]), as
   illustrated in Figure 1.

         +--------------------+               +--------------+
         |                    | <------------ |              |
         |     MUA (M)        |               | IMAPv4Rev1   |
         |                    |               |  Server      |
         |                    | ------------> | (Server I)   |
         +--------------------+               +--------------+
                ^    |                              ^     |
                |    |                              |     |
                |    |                              |     |
                |    |                              |     |
                |    |                              |     |
                |    |                              |     |
                |    |                              |     v
                |    |                        +--------------+
                |    |----------------------> |   SMTP       |
                |                             |   Submit     |
                |-----------------------------|   Server     |
                                              |  (Server S)  |
                                              +--------------+

   Figure 1: Lemonade "forward without download"

   Lemonade "forward without download" allows a Messaging User Agent to
   compose and forward an e-mail combining fragments that are located in
   an IMAP server, without having to download these fragments to the



Maes, et al.            Expires November 29, 2006               [Page 8]

Internet-Draft            LEMONADE profile bis                  May 2006


   client.

   There are two ways to perform "forward without download" based on
   where the message assembly takes place.  The first uses extended
   APPEND command [CATENATE] to edit a draft message in the message
   store and cause the message assembly on the IMAP server.  The second
   uses a succession of BURL and BDAT commands to submit and assemble
   through concatenation, message data from the client and external data
   fetched from the provided URL.  The two subsequent sections provide
   step-by-step instructions on how "forward without download" is
   achieved.

2.4.1.  Message assembly using IMAP CATENATE extension

   In the [BURL]/[CATENATE] variant of the Lemonade "forward without
   download" strategy, messages are initially composed and edited within
   an MUA.  The [CATENATE] extension to [RFC3501] is then used to create
   the messages on the IMAP server by transmitting new text and
   assembling them.  The [RFC4315] IMAP extension is used by the client
   in order to learn the UID of the created messages.  Finally a
   [URLAUTH] format URL is given to a [Submit] server for submission
   using the [BURL] extension.

   The flow involved to support such a use case consists of:

   M: {to I -- Optional} The client connects to the IMAP server,
   optionally starts TLS (if data confidentiality is required),
   authenticates, opens a mailbox ("INBOX" in the example below) and
   fetches body structures (See [RFC3501]).

   Example:

            M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
            I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
               ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
               "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
               "trip.txt")
               "<960723163407.20117h@washington.example.com>"
               "Your trip details" "BASE64" 4554 73) "MIXED"))
            I: A0051 OK completed

   M: {to I} The client invokes CATENATE (See [CATENATE] for details of
   the semantics and steps) -- this allows the MUA to create messages on
   the IMAP server using new data combined with one or more message
   parts already present on the IMAP server.

   Note that the example for this step doesn't use the LITERAL+
   [RFC2088] extension.  Without LITERAL+ the new message is constructed



Maes, et al.            Expires November 29, 2006               [Page 9]

Internet-Draft            LEMONADE profile bis                  May 2006


   using 3 round-trips.  If LITERAL+ is used, the new message can be
   constructed using one round-trip.

         M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent)
            CATENATE (TEXT {475}
         I: + Ready for literal data
         M: Message-ID: <419399E1.6000505@caernarfon.example.org>
         M: Date: Thu, 12 Nov 2004 16:57:05 +0000
         M: From: Bob Ar <bar@example.org>
         M: MIME-Version: 1.0
         M: To: foo@example.net
         M: Subject: About our holiday trip
         M: Content-Type: multipart/mixed;
         M:     boundary="------------030308070208000400050907"
         M:
         M: --------------030308070208000400050907
         M: Content-Type: text/plain; format=flowed
         M:
         M: Our travel agent has sent the updated schedule.
         M:
         M: Cheers,
         M: Bob
         M: --------------030308070208000400050907
         M:  URL "/INBOX;UIDVALIDITY=385759045/;
            UID=25627/;Section=2.MIME" URL "/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
         I: + Ready for literal data
         M:
         M: --------------030308070208000400050907--
         M: )
         I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed

   M: {to I} The client uses GENURLAUTH command to request a URLAUTH URL
   (See [URLAUTH]).
   I: {to M} The IMAP server returns a URLAUTH URL suitable for later
   retrieval with URLFETCH (See [URLAUTH] for details of the semantics
   and steps).

         M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent;
            UIDVALIDITY=387899045/;uid=45;expire=2005-10-
            28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
         I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
            UIDVALIDITY=387899045/;uid=45;expire=
            2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:91354a473744909de610943775f92038"
         I: A0054 OK GENURLAUTH completed

   M: {to S} The client connects to the mail submission server and



Maes, et al.            Expires November 29, 2006              [Page 10]

Internet-Draft            LEMONADE profile bis                  May 2006


   starts a new mail transaction.  It uses BURL to let the SMTP submit
   server fetch the content of the message from the IMAP server (See
   [BURL] for details of the semantics and steps -- this allows the MUA
   to authorize the SMTP submit server to access the message composed as
   a result of the CATENATE step).  Note that the second EHLO command is
   required after a successful STARTTLS command.  Also note that there
   might be a third required EHLO command if the second EHLO response
   doesn't list any BURL options.  Section 2.4.2 demonstrates this.

         S: 220 owlry.example.org ESMTP
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL imap
         S: 250-CHUNKING
         S: 250-AUTH PLAIN
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250-STARTTLS
         S: 250 ENHANCEDSTATUSCODES
         M: STARTTLS
         S: 220 Ready to start TLS
         ...TLS negotiation, subsequent data is encrypted...
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL imap
         S: 250-CHUNKING
         S: 250-AUTH PLAIN
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250 ENHANCEDSTATUSCODES
         M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
         S: 235 2.7.0 PLAIN authentication successful.
         M: MAIL FROM:<bob.ar@example.org>
         S: 250 2.5.0 Address Ok.
         M: RCPT TO:<foo@example.net>
         S: 250 2.1.5 foo@example.net OK.
         M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
            uid=45/;urlauth=submit+bar:internal:
            91354a473744909de610943775f92038 LAST

   S: {to I} The mail submission server uses URLFETCH to fetch the
   message to be sent (See [URLAUTH] for details of the semantics and



Maes, et al.            Expires November 29, 2006              [Page 11]

Internet-Draft            LEMONADE profile bis                  May 2006


   steps.  The so-called "pawn-ticket" authorization mechanism uses a
   URI which contains its own authorization credentials.).
   I: {to S} Provides the message composed as a result of the CATENATE
   step).

   Mail submission server opens IMAP connection to the IMAP server:

         I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
            CATENATE URLAUTH] imap.example.com
            IMAP server ready
         S: a000 STARTTLS
         I: a000 Start TLS negotiation now
         ...TLS negotiation, if successful - subsequent data
            is encrypted...
         S: a001 LOGIN submitserver secret
         I: a001 OK submitserver logged in
         S: a002 URLFETCH "imap://bob.ar@example.org/Sent;
            UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
            internal:91354a473744909de610943775f92038"
         I: * URLFETCH "imap://bob.ar@example.org/Sent;
            UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
            internal:91354a473744909de610943775f92038" {15065}
         ...message body follows...
         S: a002 OK URLFETCH completed
         I: a003 LOGOUT
         S: * BYE See you later
         S: a003 OK Logout successful

   Note that if the IMAP server doesn't send CAPABILITY response code in
   the greeting, the mail submission server must issue the CAPABILITY
   command to learn about supported IMAP extensions as described in
   [RFC3501].

   Also, if data confidentiality is not required the mail submission
   server may omit the STARTTLS command before issuing the LOGIN
   command.

   S: {to M} Submission server assembles the complete message and if the
   assembly succeeds it returns OK to the MUA:

         S: 250 2.5.0 Ok.

   M: {to I} The client marks the message containing the forwarded
   attachment on the IMAP server.

         M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
         I: A0053 OK STORE completed




Maes, et al.            Expires November 29, 2006              [Page 12]

Internet-Draft            LEMONADE profile bis                  May 2006


   Note: the UID STORE command shown above will only work if the marked
   message is in the currently selected mailbox, otherwise requiring a
   SELECT.  This command can be omitted, being for metadata only.  The
   $Forwarded IMAP keyword is described in Section 2.8.

   M: {to I} The client removes the \Draft flag, causing the message to
   be promoted to a sent item.

         M: A0054 SELECT Sent (CONDSTORE)
         I: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
         I: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
         I: * 91 EXISTS
         I: * 1 RECENT
         I: * OK [UNSEEN 1]
         I: * OK [UIDVALIDITY 1134746583]
         I: * OK [UIDNEXT 192]
         I: * OK [HIGHESTMODSEQ 88]
         I: A0054 OK [READ-WRITE] Completed
         M: A0055 UID STORE 45 -FLAGS.SILENT (\Draft)
         I: A0055 OK STORE completed

   Note: This is a behaviour choice on the part of the client - the
   client need not save sent items, and may instead either mark a sent
   draft Deleted, or copy it to another folder.  Current IMAP clients
   typically expect a draft to be unsent, but this is not required
   behaviour.  It is perfectly acceptable behaviour to store both drafts
   and sent copies in any folder, including the INBOX.

2.4.2.  Message assembly using SMTP CHUNKING and BURL extensions

   In the [BURL]/[RFC3030] variant of the Lemonade "forward without
   download" strategy, messages are initially composed and edited within
   an MUA.  During submission [Submit], BURL [BURL] and BDAT [RFC3030]
   commands are used to create the messages from multiple parts.  New
   body parts are supplied using BDAT commands, while existing body
   parts are referenced using [URLAUTH] format URLs in BURL commands.

   The flow involved to support such a use case consists of:
   M: {to I -- Optional} The client connects to the IMAP server,
   optionally starts TLS (if data confidentiality is required),
   authenticates, opens a mailbox ("INBOX" in the example below) and
   fetches body structures (See [RFC3501]).









Maes, et al.            Expires November 29, 2006              [Page 13]

Internet-Draft            LEMONADE profile bis                  May 2006


   Example:

            M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
            I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
               ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
               "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
               "trip.txt")
               "<960723163407.20117h@washington.example.com>"
               "Your trip details" "BASE64" 4554 73) "MIXED"))
            I: A0051 OK completed

   M: {to I} The client uses GENURLAUTH command to request URLAUTH URLs
   (See [URLAUTH]) referencing pieces of the message to be assembled.
   I: {to M} The IMAP server returns URLAUTH URLs suitable for later
   retrieval with URLFETCH (See [URLAUTH] for details of the semantics
   and steps).

         M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
            INTERNAL "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
         I: * GENURLAUTH "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:A0DEAD473744909de610943775f9BEEF"
            "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:BEEFA0DEAD473744909de610943775f9"
         I: A0054 OK GENURLAUTH completed

   M: {to S} The client connects to the mail submission server and
   starts a new mail transaction.  It uses BURL to instruct the SMTP
   submit server to fetch from the IMAP server pieces of the message to
   be sent (See [BURL] for details of the semantics and steps).

   Note that the second EHLO command is required after a successful
   STARTTLS command.  The third EHLO command is required if and only if
   the second EHLO response doesn't list any BURL options.  See
   Section 2.4.1 for an example of submission where the third EHLO
   command/response is not present.

         S: 220 owlry.example.org ESMTP
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME



Maes, et al.            Expires November 29, 2006              [Page 14]

Internet-Draft            LEMONADE profile bis                  May 2006


         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL
         S: 250-CHUNKING
         S: 250-AUTH DIGEST-MD5
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250-STARTTLS
         S: 250 ENHANCEDSTATUSCODES
         M: STARTTLS
         S: 220 Ready to start TLS
         ...TLS negotiation, subsequent data is encrypted...
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL
         S: 250-CHUNKING
         S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250 ENHANCEDSTATUSCODES
         M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
         S: 235 2.7.0 PLAIN authentication successful.
         M: EHLO potter.example.org
         S: 250-owlry.example.com
         S: 250-8BITMIME
         S: 250-BINARYMIME
         S: 250-PIPELINING
         S: 250-BURL imap imap://imap.example.org
         S: 250-CHUNKING
         S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
         S: 250-DSN
         S: 250-SIZE 10240000
         S: 250 ENHANCEDSTATUSCODES
         M: MAIL FROM:<bob.ar@example.org> BODY=BINARY
         S: 250 2.5.0 Address Ok.
         M: RCPT TO:<foo@example.net>
         S: 250 2.1.5 foo@example.net OK.
         M: BDAT 475
         M: Message-ID: <419399E1.6000505@caernarfon.example.org>
         M: Date: Thu, 12 Nov 2004 16:57:05 +0000
         M: From: Bob Ar <bar@example.org>
         M: MIME-Version: 1.0
         M: To: foo@example.net
         M: Subject: About our holiday trip
         M: Content-Type: multipart/mixed;



Maes, et al.            Expires November 29, 2006              [Page 15]

Internet-Draft            LEMONADE profile bis                  May 2006


         M:     boundary="------------030308070208000400050907"
         M:
         M: --------------030308070208000400050907
         M: Content-Type: text/plain; format=flowed
         M:
         M: Our travel agent has sent the updated schedule.
         M:
         M: Cheers,
         M: Bob
         M: --------------030308070208000400050907
         S: 250 2.5.0 OK
         M: BURL imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:A0DEAD473744909de610943775f9BEEF
         S: 250 2.5.0 OK
         M: BURL imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:BEEFA0DEAD473744909de610943775f9
         S: 250 2.5.0 OK
         M: BDAT 44 LAST
         M:
         M: --------------030308070208000400050907--

   S: {to I} The mail submission server uses URLFETCH to fetch the
   pieces of the message to be sent (See [URLAUTH] for details of the
   semantics and steps.  The so-called "pawn-ticket" authorization
   mechanism uses a URI which contains its own authorization
   credentials.).
   I: {to S} Returns the requested body parts.




















Maes, et al.            Expires November 29, 2006              [Page 16]

Internet-Draft            LEMONADE profile bis                  May 2006


   Mail submission server opens IMAP connection to the IMAP server:

         I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
            CATENATE URLAUTH] imap.example.com
            IMAP server ready
         S: a001 LOGIN submitserver secret
         I: a001 OK submitserver logged in
         S: a002 URLFETCH "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:A0DEAD473744909de610943775f9BEEF" "imap://
            bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:BEEFA0DEAD473744909de610943775f9"
         I: * URLFETCH "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:A0DEAD473744909de610943775f9BEEF" {84}
         ...message section follows...
             "imap://bob.ar@example.org/INBOX;
            UIDVALIDITY=385759045/;UID=25627/;Section=2;
            expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
            internal:BEEFA0DEAD473744909de610943775f9" {15065}
         ...message section follows...
         S: a002 OK URLFETCH completed
         I: a003 LOGOUT
         S: * BYE See you later
         S: a003 OK Logout successful

   Note that if the IMAP server doesn't send CAPABILITY response code in
   the greeting, the mail submission server must issue the CAPABILITY
   command to learn about supported IMAP extensions as described in
   [RFC3501].

   Also, if data confidentiality is required the mail submission server
   should start TLS before issuing the LOGIN command.

   S: {to M} Submission server assembles the complete message and if the
   assembly succeeds it acknowledges acceptance of the message by
   sending 250 response to the last BDAT command:

         S: 250 2.5.0 Ok, message accepted.








Maes, et al.            Expires November 29, 2006              [Page 17]

Internet-Draft            LEMONADE profile bis                  May 2006


   M: {to I} The client marks the message containing the forwarded
   attachment on the IMAP server.

         M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
         I: A0053 OK STORE completed

   Note: the UID STORE command shown above will only work if the marked
   message is in the currently selected mailbox.  This command can be
   omitted.  The $Forwarded IMAP keyword is described in Section 2.8.

2.5.  Normative statements related to forward without download

   Lemonade compliant IMAP servers MUST support IMAPv4Rev1 [RFC3501],
   CATENATE [CATENATE], UIDPLUS [RFC4315] and URLAUTH [URLAUTH].  This
   support MUST be declared via CAPABILITY [RFC3501].

   Lemonade compliant submit servers MUST support the BURL [BURL],
   8BITMIME [RFC1652], BINARYMIME [RFC3030] and CHUNKING [RFC3030].
   This support MUST be declared via EHLO [RFC2821].  BURL MUST support
   URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap"
   option following the BURL EHLO keyword (See [BURL] for more details).

   Additional normative statements are provided in other sections.

2.6.  Security Considerations for pawn-tickets.

   The so-called "pawn-ticket" authorization mechanism uses a URI, which
   contains its own authorization credentials using [URLAUTH].  The
   advantage of this mechanism is that the SMTP submit [Submit] server
   cannot access any data on the [RFC3501] server without a "pawn-
   ticket" created by the client.

   The "pawn-ticket" grants access only to the specific data that the
   SMTP submit [Submit] server is authorized to access, can be revoked
   by the client, and can have a time-limited validity.

2.7.  The fcc problem

   The "fcc problem" refers to delivering a copy of a message to a "file
   carbon copy" recipient.  By far, the most common case of fcc is a
   client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox"
   mailbox.

   In the traditional strategy, the MUA duplicates the effort spent in
   transmitting to the MSA by writing the message to the fcc destination
   in a separate step.  This may be a write to a local disk file or an
   APPEND to a mailbox on an IMAP server.  The latter is one of the "
   repetitive network data transmissions" which represents the "problem"



Maes, et al.            Expires November 29, 2006              [Page 18]

Internet-Draft            LEMONADE profile bis                  May 2006


   aspect of the "fcc problem".

   The [CATENATE] extension to [RFC3501] can be used to address the fcc
   problem.  The final message is constructed in the mailbox designed
   for outgoing mail.  Note that the [CATENATE] extension can only
   create a single message and only on the server which stages the
   outgoing message for submission.  Additional copies of the message
   can be created on the same server using one or more COPY commands.

2.8.  Registration of $Forwarded IMAP keyword

   The $Forwarded IMAP keyword is used by several IMAP clients to
   specify that the marked message was forwarded to another email
   address, embedded within or attached to a new message.  A mail client
   sets this keyword when it successfully forwards the message to
   another email address.  Typical usage of this keyword is to show a
   different (or additional) icon for a message that has been forwarded.
   Once set the flag SHOULD NOT be cleared.

   Lemonade compliant servers MUST be able to store the $Forwarded
   keyword.  They MUST preserve it on the COPY operation.  The servers
   MUST support the SEARCH KEYWORD $Forwarded.





























Maes, et al.            Expires November 29, 2006              [Page 19]

Internet-Draft            LEMONADE profile bis                  May 2006


3.  Message Submission

   LEMONADE compliant mail submission servers are expected to implement
   the following set of SMTP extensions to make message submission
   efficient.

   Lemonade clients should take advantage of these features.

3.1.  Pipelining

   Mobile clients regularly use networks with a relatively high latency.
   Avoidance of round-trips within a transaction has a great advantage
   for the reduction in both bandwidth and total transaction time.  For
   this reason LEMONADE compliant mail submission servers MUST support
   the SMTP Service Extensions for Command Pipelining [RFC2197].

   Clients SHOULD pipeline SMTP commands when possible.

3.2.  DSN Support

   LEMONADE compliant mail submission servers MUST support SMTP service
   extensions for delivery status notifications [RFC3461].

3.3.  Message size declaration

   LEMONADE compliant mail submission servers MUST support the SMTP
   Service Extension for Message Size Declaration [RFC1870].

   LEMONADE compliant mail submission servers MUST "expand" all BURL
   parts before enforcing a message size limit.

   A LEMONADE compliant client SHOULD use message size declaration.  In
   particular the client MUST NOT send a message to a mail submission
   server, if it knows that the message exceeds the maximal message size
   advertised by the submission server.

3.4.  Enhanced status code Support

   LEMONADE compliant mail submission servers MUST support SMTP Service
   Extension for Returning Enhanced Error Codes [RFC2034].

3.5.  TLS

   LEMONADE Compliant mail submission servers MUST support SMTP Service
   Extension for Secure SMTP over TLS [RFC3207].






Maes, et al.            Expires November 29, 2006              [Page 20]

Internet-Draft            LEMONADE profile bis                  May 2006


4.  Message Store

   Lemonade compliant message store services provide an IMAP service
   with the following set of extensions in order to provide both
   efficient access to the message store and support constrained devices
   more effectively.

4.1.  Quick resynchronization

   LEMONADE Compliant IMAP servers MUST support the CONDSTORE
   [CONDSTORE] extension.  It allows a client to quickly resynchronize
   any mailbox by asking the server to return all flag changes that have
   occurred since the last known mailbox synchronization mark.

   [DISC-IMAP] shows how to perform quick mailbox resynchronization.

   In addition, LEMONADE Compliant IMAP servers MUST support the
   RECONNECT [RECONNECT] extension to provide quick reconnection
   facilities in case the transport layer is cut, whether accidentally
   or as part of a change in network.

4.2.  Message part handling

   LEMONADE Compliant IMAP servers MUST support the BINARY [IMAP-BINARY]
   extension.  This moves MIME body part decoding operations from the
   client to the server.  The decoded data is equal or less than the
   encoded representation, so this reduces bandwidth effectively.

   [IMAP-BINARY] allows for servers to refuse to accept uploaded
   messages containing binary data, however LEMONADE Compliant IMAP
   servers SHALL always accept binary encoded MIME messages in APPEND
   commands for any folder.

   [CONVERT] MUST also be supported by servers, which allows clients to
   request conversions between media types, and allows for scaling
   images, etc.  This provides the ability to view attachments (and
   sometimes body parts) without the facility to cope with a wide range
   of media types, or to efficiently view attachments.

4.3.  Compression

   The server MUST support the compression mechanisms described in
   [CONVERT].

   <<Editor's Note: Exactly which combination of compression extensions
   will be supported, and which of those are to be MUST/SHOULD/MAY is an
   open issue.  It is generally agreed that TLS Deflate compression will
   be included as, at least, a MAY, but otherwise there is little



Maes, et al.            Expires November 29, 2006              [Page 21]

Internet-Draft            LEMONADE profile bis                  May 2006


   consensus.  Therefore this section has one first paragraph and two
   second paragraphs.  Please pick one.>>

   The IETF has for some time generally agreed that compression is best
   handled at as low a level as possible, therefore Lemonade compliant
   IMAP servers SHOULD support the Deflate compression algorithm for
   TLS, as defined in [RFC3749].

   However, the working group acknowledges that for many endpoints, this
   is a rarely deployed technology, as as such, Lemonade compliant IMAP
   servers MUST provide [LZIP] support for fallback object-level
   compression, where TLS is not actively providing compression.

   However, the working group acknowledges that for many endpoints, this
   is a rarely deployed technology, as as such, Lemonade compliant IMAP
   servers MUST provide [COMPRESS] support for fallback application-
   level stream compression, where TLS is not actively providing
   compression.

4.4.  Out of band notifications

   Notifications (server to client) as discussed in [notifications].
   Server to server notifications discussed in [notifications] describes
   how NF interacts with the notifications mechanisms.

   <<Editor's Note: This is a placeholder section, awaiting
   clarification of notifications.>>

4.5.  Virtual Folders

   Lemonade compliant IMAP servers provide a mechanism for clients to
   avoid handling an entire mailbox, instead accessing a view of the
   mailbox defined previously.  This technique, common in many desktop
   clients as a client-side capability, is useful for constrained
   clients to minimize the quantity of messages and notification data.

   This virtual folder mechanism is defined in [vfolder].

4.6.  Additional IMAP extensions

   Lemonade compliant IMAP servers MUST support the NAMESPACE [RFC2342]
   extension.  The extension allows clients to discover shared mailboxes
   and mailboxes belonging to other users, and provide a normalized
   heirarchy view of the mailboxes available.

   Lemonade compliant IMAP servers MUST support the LITERAL+ [RFC2088]
   extension.  The extension allows clients to save a round trip each
   time a non-synchronizing literal is sent.



Maes, et al.            Expires November 29, 2006              [Page 22]

Internet-Draft            LEMONADE profile bis                  May 2006


   Lemonade compliant IMAP servers MUST support the ESEARCH [ESEARCH]
   extension.  The extension allows clients to efficiently find the
   first or last messages, find a count of matching messages, and obtain
   a list of matching messages in a considerably more compact
   representation.

   Lemonade compliant IMAP servers MUST support the METADATA
   [ANNOTATEMORE] extension.  This allows metadata to be stored against
   mailboxes, which is a facility used by other extensions mandated by
   this profile.

   Lemonade compliant IMAP servers MUST support the IDLE [RFC2177]
   extension.  The extension allows clients to receive unsolicited
   notifications about changes in the selected mailbox, without needing
   to poll for changes.  The responses forming these notifications MUST
   be sent in a timely manner when such changes happen.

   Lemonade Compliant IMAP servers MUST support IMAP over TLS [RFC3501]
   as required by [RFC3501].  As noted above, servers SHOULD support the
   deflate compression algorithm for TLS, as specified in [RFC3749]































Maes, et al.            Expires November 29, 2006              [Page 23]

Internet-Draft            LEMONADE profile bis                  May 2006


5.  Summary of the required IMAP and SMTP extensions

   +-------------------------+----------------------------------------+
   |  Name of SMTP extension |                 Comment                |
   +-------------------------+----------------------------------------+
   |        PIPELINING       |               Section 3.1              |
   |                         |                                        |
   |           DSN           |               Section 3.2              |
   |                         |                                        |
   |           SIZE          |               Section 3.3              |
   |                         |                                        |
   |   ENHANCEDSTATUSCODES   |               Section 3.4              |
   |                         |                                        |
   |         STARTTLS        |               Section 3.5              |
   |                         |                                        |
   |           BURL          |                Section 2               |
   |                         |                                        |
   | URLAUTH support in BURL |                Section 2               |
   |                         |                                        |
   |   CHUNKING, BINARYMIME  |               Section 2.5              |
   |                         |                                        |
   |         8BITMIME        |            Required by BURL            |
   |                         |                                        |
   |           AUTH          | Required by Submission.  See [RFC2554] |
   +-------------------------+----------------------------------------+


























Maes, et al.            Expires November 29, 2006              [Page 24]

Internet-Draft            LEMONADE profile bis                  May 2006


    +-----------------------------------+----------------------------+
    | Name of IMAP extension or feature |           Comment          |
    +-----------------------------------+----------------------------+
    |             NAMESPACE             |         Section 4.6        |
    |                                   |                            |
    |             CONDSTORE             |         Section 4.1        |
    |                                   |                            |
    |              STARTTLS             | Required by IMAP [RFC3501] |
    |                                   |                            |
    |     URLAUTH, CATENATE, UIDPLUS    |          Section 2         |
    |                                   |                            |
    |              LITERAL+             |         Section 4.6        |
    |                                   |                            |
    |                IDLE               |         Section 4.6        |
    |                                   |                            |
    |      $Forwarded IMAP keyword      |         Section 2.8        |
    |                                   |                            |
    |               BINARY              |         Section 4.2        |
    |                                   |                            |
    |             RECONNECT             |         Section 4.1        |
    |                                   |                            |
    |              ESEARCH              |         Section 4.6        |
    |                                   |                            |
    |              VFOLDER              |         Section 4.5        |
    |                                   |                            |
    |              CONVERT              |         Section 4.2        |
    |                                   |                            |
    |                LZIP               |         Section 4.3        |
    |                                   |                            |
    |          COMPRESS=DEFLATE         |         Section 4.3        |
    |                                   |                            |
    |              METADATA             |         Section 4.6        |
    |                                   |                            |
    |   LPROVISION, LSETPREF, LGETPREF  |         Section 4.4        |
    +-----------------------------------+----------------------------+
















Maes, et al.            Expires November 29, 2006              [Page 25]

Internet-Draft            LEMONADE profile bis                  May 2006


6.  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 [MEM-req].  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 November 29, 2006              [Page 26]

Internet-Draft            LEMONADE profile bis                  May 2006


7.  OMA MEM Architecture

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













































Maes, et al.            Expires November 29, 2006              [Page 27]

Internet-Draft            LEMONADE profile bis                  May 2006


8.  OMA MEM Deployment Issues

   The OMA MEM Architecture document [MEM-arch] 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 November 29, 2006              [Page 28]

Internet-Draft            LEMONADE profile bis                  May 2006


9.  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 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 November 29, 2006              [Page 29]

Internet-Draft            LEMONADE profile bis                  May 2006


10.  IETF LEMONADE Architecture

   This section gives a brief introduction to the LEMONADE Architecture.

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

   The LEMONADE profile bis assumes: <<Editor's note: remove redundant
   information from the list below.>>

   o  IMAP protocol [RFC3501] including LEMONADE profile extensions
      [profile]

   o  Submit protocol (SUBMIT [Submit], profile of ESMTP [RFC2821])
      including LEMONADE profile extensions

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

   o  LEMONADE profile compliant Submit server connected to MTA via
      ESMTP




Maes, et al.            Expires November 29, 2006              [Page 30]

Internet-Draft            LEMONADE profile bis                  May 2006


   o  Lemonade profile message store / Submit server protocols (URLAUTH)
      (see [profile] and [URLAUTH]).

   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 [internetemailarch]

   Note that in Figure 16 the IMAP server and Submit server are
   represented connected to MTAs (Mail Transfer Agents) via ESMTP
   [RFC1861].  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 November 29, 2006              [Page 31]

Internet-Draft            LEMONADE profile bis                  May 2006


11.  LEMONADE profile bis logical architecture

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

11.1.  Relationship between the OMA MEM and LEMONADE logical
       architectures

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

   As described in Section 10, the LEMONADE profile bis assumes LEMONADE
   profile bis compliant IMAP stores and Submit servers.  Because the
   LEMONADE profile bis extends the IMAP store and the submit server,



Maes, et al.            Expires November 29, 2006              [Page 32]

Internet-Draft            LEMONADE profile bis                  May 2006


   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 ([MEM-arch])
   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).

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

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

   Figure 18 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 November 29, 2006              [Page 33]

Internet-Draft            LEMONADE profile bis                  May 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 18: Architecture to support non-LEMONADE enhanced IMAP
   servers with a LEMONADE realization of OMA MEM enabler.

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

11.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 19 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 November 29, 2006              [Page 34]

Internet-Draft            LEMONADE profile bis                  May 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 19: 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 19, the server may be a separate proxy.


















Maes, et al.            Expires November 29, 2006              [Page 35]

Internet-Draft            LEMONADE profile bis                  May 2006


12.  Filters and server to client notifications and LEMONADE

   OMA MEM RD [MEM-req] and AD [MEM-arch] emphasize the need to provide
   mechanisms for server to client notifications of email events and
   filtering.  Figure 20 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 20: Filtering mechanism defined in LEMONADE architecture

   In Figure 20, 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
      email messages.  They can be defined as SIEVE filters [SIEVE].
      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 [vfolder]
      as described in [vfolder] and [notifications].



Maes, et al.            Expires November 29, 2006              [Page 36]

Internet-Draft            LEMONADE profile bis                  May 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 [ManageSieve]

   o  VF: via virtual folder mechanisms as discussed in [vfolder] and
      [notifications]










































Maes, et al.            Expires November 29, 2006              [Page 37]

Internet-Draft            LEMONADE profile bis                  May 2006


13.  LEMONADE Profile bis features

   <<Editor's note: This section will be expended with subsection
   discussing each topic with some details or examples.>>

   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 [OMAMEMrealization].

   <<Editor's note: This text will be updated when all features are
   appropriately addressed.  [OMAMEMrealization] 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 [profile] 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 [notifications].
      Server to server notifications discussed in [notifications]
      describes how NF interacts with the notifications mechanisms.

   o  Filters as discussed in [notifications], [vfolder],
      [searchwithin], [SIEVE] and [sieveinIMAP].  Events that can be
      bound to notifications are described in [msgevents].  Filter
      remote management are discussed in [notifications] and [vfolder].
      For NF, it MAY rely on [ManageSieve]

   o  Virtual folders as discussed in [vfolder]

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

   o  Quick reconnect as discussed in [CONNECT]

   o  Compression as discussed in [CONVERT], [LZIP] and [COMPRESS].

   o  Intermediaries as discussed in [intermediaries].  Best practices
      are discussed in [bestpractices_deployment].  Lemonade protocols
      MAY also follow [TCPChallengedEnvironment]




Maes, et al.            Expires November 29, 2006              [Page 38]

Internet-Draft            LEMONADE profile bis                  May 2006


   o  Proxies and other intermediaries that provide protocol support
      disrupt conventional IETF security models and require object level
      encryption as discussed in [CONVERT]. [notifications] further
      discusses the use for notification encryption.

   o  Message recall within SUBMIT domain based on [MSGTRACK].













































Maes, et al.            Expires November 29, 2006              [Page 39]

Internet-Draft            LEMONADE profile bis                  May 2006


14.  Security Considerations

   Security considerations on Lemonade "forward without download" are
   discussed throughout Section 2.  Additional security considerations
   can be found in [RFC3501] and other documents describing other SMTP
   and IMAP extensions comprising the Lemonade Profile.

   Note that the mandatory-to-implement authentication mechanism for
   SMTP submission is described in [Submit].  The mandatory-to-implement
   authentication mechanism for IMAP is described in [RFC3501].

14.1.  Confidentiality Protection of Submitted Messages

   When clients submit new messages, link protection such as TLS guards
   against an eavesdropper seeing the contents of the submitted message.
   It's worth noting, however, that even if TLS is not used, the
   security risks are no worse if BURL is used to reference the text
   than if the text is submitted directly.  If BURL is not used, an
   eavesdropper gains access to the full text of the message.  If BURL
   is used, the eavesdropper may or may not be able to gain such access,
   depending on the form of BURL used.  For example, some forms restrict
   use of the URL to an entity authorized as a submission server or a
   specific user.

14.2.  TLS

   When LEMONADE clients use the BURL extension to mail submission, an
   extension that requires sending a URLAUTH token to the mail
   submission server, such a token should be protected from interception
   to avoid a replay attack that may disclose the contents of the
   message to an attacker.  TLS based encryption of the mail submission
   path will provide protection against this attack.

   LEMONADE clients SHOULD use TLS-protected IMAP and mail submission
   channels when using BURL-based message submission to protect the
   URLAUTH token from interception.

   LEMONADE compliant mail submission servers SHOULD use TLS-protected
   IMAP connections when fetching message content using the URLAUTH
   token provided by the LEMONADE client.

   When a client uses SMTP STARTTLS to send a BURL command which
   references non-public information, there is a user expectation that
   the entire message content will be treated confidentially.  To meet
   this expectation, the message submission server should use STARTTLS
   or a mechanism providing equivalent data confidentiality when
   fetching the content referenced by that URL.




Maes, et al.            Expires November 29, 2006              [Page 40]

Internet-Draft            LEMONADE profile bis                  May 2006


14.3.  Additional extensions and deployment models

   This specification provides no additional 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 November 29, 2006              [Page 41]

Internet-Draft            LEMONADE profile bis                  May 2006


15.  IANA considerations

   This document doesn't require any IANA registration or action that
   are not covered by the different drafts and RFCs included in the
   realization described in this document.

   We note the reserved mailbox / folder names in [vfolder].












































Maes, et al.            Expires November 29, 2006              [Page 42]

Internet-Draft            LEMONADE profile bis                  May 2006


16.  Future work

   o  The different drafts and RFCs referenced in this document must be
      completed and separated into normative and informative references.

   o  Expansion of Section 13

   o  Text will be updated as described in editor's notes











































Maes, et al.            Expires November 29, 2006              [Page 43]

Internet-Draft            LEMONADE profile bis                  May 2006


17.  Version history

   o  Version 02:

      *  Update of references and how they are displayed in teh text
         (Comments from Randy Gellens)

      *  Update of list of extensions to support as MUST by the Lemonade
         Profile Bis

      *  Update of options for compression via placeholder imap-
         compression section describing compression requirements

      *  Update of support of TCP chalenged environments

      *  Update of support of object level encryption

      *  Clarified the use of $Forwarded in the examples, and
         demonstrated how to remove the \Draft flag from the sent
         message

      *  Clarified $Forwarded

      *  Added RECONNECT to imap-condstore section

      *  Add new section imap-bodypart, "Message part handling",
         describing BINARY and CONVERT requirements

      *  Added placeholder section for notifications

      *  Added various extensions to imap-other section, and added
         clarifying comments to IDLE, NAMESPACE, and a further
         references to TLS DEFLATE compression

      *  Added extension names to IMAP table

      *  Fixed all issues found with Lemonade profile ([profile]) so
         far.

   o  Version 01:

      *  LEMONADE profile [profile] has been introduced in-line, with
         some updates / corrections.

      *  Subsequent re-organization of the text

      *  Details of extensions proper to Lemonade Profile-bis have been
         updated to refer to the drafts newly accepted as WG IETF



Maes, et al.            Expires November 29, 2006              [Page 44]

Internet-Draft            LEMONADE profile bis                  May 2006


         drafts.

      *  Addition of appendix on attachements streaming.

   o  Version 00:

      *  It evolved from a combination of the content of LEMONADE
         profile [profile] and the  OMA MEM realization internet draft
         [OMAMEMrealization].










































Maes, et al.            Expires November 29, 2006              [Page 45]

Internet-Draft            LEMONADE profile bis                  May 2006


18.  Acknowledgements

   The editors acknowledge and appreciate 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).











































Maes, et al.            Expires November 29, 2006              [Page 46]

Internet-Draft            LEMONADE profile bis                  May 2006


Appendix A.  Streaming attachments

   <<Editor's note: This section is introduced as a reminder that a
   draft is due on this topic.  It is expected to be moved to that
   draft.  Otherwise, it may be expanded and remain in this document
   (possibly as a main section) when well enough documented.>>

   <<Editor's note: Support for this capability is expected to remain
   optional.>>



     +----------+          +--------+       +---------+
     | LEMONADE |    (2)   | Media  |  (3)  | Media   |
     |  IMAP    |<-------->| Server |<----->|Converter|
     | Store    |          |        |       |         |
     +----------+          +--------+       +---------+
          ^                     ^
          |                     |
          |(1)                  |
          |                     |(4)
          |                     |
     +----V---+                 |
     |        |                 |
     | Client <-----------------|
     |        |
     +--------+


   Figure 21: LEMONADE architecture to support streaming and conversion
   of attachments

   In Figure 21:

   o  (1) Designates:

      *  (a) The request (to be defined by Lemonade) for content
         streaming (possibly with conversion) sent by the client to the
         IMAP store.

      *  (b) The response from the IMAP store (if any).

   o  (2) Designates:

      *  A yet to be defined rest to initiate streaming of converted
         content to the client.





Maes, et al.            Expires November 29, 2006              [Page 47]

Internet-Draft            LEMONADE profile bis                  May 2006


      *  The response

   o  (3) Designates :

      *  (a) A yet to be defined request by the media server to convert
         content as requested by the client.  This could be based on OMA
         STI. <<Editor's note: Reference will be added later.>>

      *  (b) The response

   o  (4) Designates:

      *  (a) The signaling between the Media Server and teh client to
         initiate and control streaming of the media

      *  (b) The actual media streaming

   o  This could involve SIP, RTP, RTSP, ... <<Editor's note: References
      will be added later after details are agreed upon.>>

   o  <<Editor's note: Open issue: Could IMAP store issue the signalling
      (e.g.  SIP third party call control) or does it have to be solely
      between client and media server>>




























Maes, et al.            Expires November 29, 2006              [Page 48]

Internet-Draft            LEMONADE profile bis                  May 2006


19.  References

19.1.  Normative References

   [RFC1652]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
              RFC 1652, July 1994.

   [RFC1870]  Klensin, J., Freed, N., and K. Moore, "SMTP Service
              Extension for Message Size Declaration", STD 10, RFC 1870,
              November 1995.

   [RFC2034]  Freed, N., "SMTP Service Extension for Returning Enhanced
              Error Codes", RFC 2034, October 1996.

   [RFC2088]  Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
              January 1997.

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

   [RFC2197]  Freed, N., "SMTP Service Extension for Command
              Pipelining", RFC 2197, September 1997.

   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
              RFC 2554, March 1999.

   [RFC3030]  Vaudreuil, G., "SMTP Service Extensions for Transmission
              of Large and Binary MIME Messages", RFC 3030,
              December 2000.

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

   [RFC2342]  Newman, C., "IMAP4 Namespace", RFC 2342, May 1998.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [RFC4315]  Crispin, M., "Internet Message Access Protocol (IMAP) -
              UIDPLUS extension", RFC 4315, December 2005.

   [RECONNECT]
              Wilson, C. and A. Melnikov, "Internet Message Access
              Protocol (IMAP) - URLAUTH Extension",



Maes, et al.            Expires November 29, 2006              [Page 49]

Internet-Draft            LEMONADE profile bis                  May 2006


              draft-ietf-lemonade-reconnect-xx (work in progress).

   [CONVERT]  Maes, S. and R. Cromwell, "CONVERT",
              draft-ietf-lemonade-convert-01 (work in progress),
              January 2006.

   [URLAUTH]  Crispin, M. and C. Newman, "Internet Message Access
              Protocol (IMAP) - URLAUTH Extension",
              draft-ietf-lemonade-urlauth-xx (work in progress).

   [BURL]     Newman, C., "Message Composition",
              draft-ietf-lemonade-burl-xx (work in progress).

   [CATENATE]
              Resnick, P., "Internet Message Access Protocol (IMAP)
              CATENATE Extension", draft-ietf-lemonade-catenate-xx (work
              in progress).

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

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

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

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

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

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

   [Submit]   Gellens, R. and J. Klensin, "Message Submission for Mail",
              work in progress, draft-gellens-submit-bis, February 2006.

   [TLS]      Dierks, T., Allen, C., Treese, W., Karlton, P., Freier,
              A., and P. Kocher, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC3749]  Hollenbeck, S., "Transport Layer Security Protocol
              Compression Methods", RFC 3749, May 2004.




Maes, et al.            Expires November 29, 2006              [Page 50]

Internet-Draft            LEMONADE profile bis                  May 2006


   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

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

   [vfolder]  Maes, S. and et Al., "Persistent Virtual Folder extension
              to the IMAP Protocol", draft-ietf-lemonade-vfolder-xx
              (work in progress).

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

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

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

   [OMA-EMN]  "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.

   [IMAPURL]  Newman, C., Melnikov, A., and S. Maes, "IMAP URL Scheme",
              draft-ietf-lemonade-rfc2192bis-xx (work in progress).

   [CONDSTORE]
              Melnikov, A. and S. Hole, "IMAP Extension for Conditional
              STORE operation", draft-ietf-imapext-condstore-xx (work in
              progress).

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

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

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



Maes, et al.            Expires November 29, 2006              [Page 51]

Internet-Draft            LEMONADE profile bis                  May 2006


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

   [LZIP]     Maes, S. and R. Cromwell, "COMPRESSION",
              draft-ietf-lemonade-compress-xx (work in progress).

   [COMPRESS]
              Gulbrandsen, A., "The IMAP COMPRESS=DEFLATE extension",
              draft-gulbrandsen-imap-deflate-02 (work in progress),
              March 2006.

   [ESEARCH]  Melnikov, A. and D. Cridland, "IMAP4 extension to SEARCH
              command for controlling what kind of information  is
              returned", draft-melnikov-imap-search-ret-02 (work in
              progress), October 2005.

   [ANNOTATEMORE]
              Daboo, C., "IMAP ANNOTATEMORE Extension",
              draft-daboo-imap-annotatemore-08 (work in progress),
              November 2005.

   [searchwithin]
              Maes, S. and R. Cromwell, "WITHIN Search extension to the
              IMAP Protocol", draft-ietf-lemonade-search-within-xx (work
              in progress).

   [ManageSieve]
              Martin, T. and A. Melnikov, "A Protocol for Remotely
              Managing Sieve Scripts", work in
              progress, draft-martin-managesieve, February 2006.

   [Mailbox.Annotation]
              Daboo, C., "IMAP ANNOTATEMORE Extension", work in
              progress, draft-daboo-imap-annotatemore, November 2005.

   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

   [MSGTRACK]
              Hansen, T., "Message Tracking Model and Requirements",
              RFC 3888, September 2004.

   [IMAP-BINARY]
              Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
              April 2003.





Maes, et al.            Expires November 29, 2006              [Page 52]

Internet-Draft            LEMONADE profile bis                  May 2006


19.2.  Informative References

   [TCPChallengedEnvironment]
              Maes, S. and et Al., "Lemonade in TCP Challenged
              Environments",
              draft-maes-lemonade-tcp-challenged-environments-xx (work
              in progress).

   [bestpractices_deployment]
              Gellens, R., "Deployment Considerations for lemonade-
              compliant Mobile Email",
              draft-ietf-lemonade-deployments-xx (work in progress).

   [DISC-IMAP]
              Melnikov, A., "Synchronization Operations For Disconnected
              Imap4 Clients", draft-melnikov-imap-disc-xx (work in
              progress).

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

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

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






















Maes, et al.            Expires November 29, 2006              [Page 53]

Internet-Draft            LEMONADE profile bis                  May 2006


Authors' Addresses

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

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


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

   Email: Alexey.Melnikov@isode.com


   Dave Cridland (editor)
   Inventure Systems Ltd
   21, Heol Bronwydd
   Caerfyrddin, Cymru  SA31 2AJ
   GB

   Email: dave.cridland@invsys.co.uk






















Maes, et al.            Expires November 29, 2006              [Page 54]

Internet-Draft            LEMONADE profile bis                  May 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 November 29, 2006              [Page 55]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/