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

Versions: 00 01 02 03 04 05 06 07 RFC 4550

Lemonade
Internet Draft: Lemonade Profile                             S. H. Maes
Document: draft-ietf-lemonade-profile-00.txt                A. Melnikov
Expires: January 2005                                         July 2004


                             Lemonade Profile

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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.

Abstract

   This document describes the Lemonade profile to allow clients to
   submit new email messages incorporating content which resides on
   locations external to the client ("forward without download") and to
   optimize e-mail exchanges between clients and servers in a mobile
   environment.

   The Lemonade profile relies upon extensions to other protocols;
   specifically URLAUTH, CATENATE, Lemonade Command Extensions in the
   IMAP protocol [RFC 3501] and BURL in the SUBMIT protocol [RFC 2476].

   It also provides optimization in a mobile setting, aimed at
   delivering extended functionality for mobile devices with limited
   resources by relying on Lemonade Server to Client Notifications to
   support to push crucial changes actively to a client, rather then
   requiring the client to initiate contact to ask for state changes.





Maes                    Expires - January 2005                [Page 1]

                          <Lemonade Profile>                 July 2004


   In addition, the Lemonade profile contains Lemonade Command
   extensions for email filter management, message delivery, maintaining
   up-to-date personal information and quick reconnect.

Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   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 [RFC2119].


Table of Contents

   Status of this Memo...............................................1
   Abstract..........................................................1
   Conventions used in this document.................................2
   Table of Contents.................................................2
   1. Introduction...................................................3
   2. The Lemonade Pull Model........................................3
      2.1. Motivations...............................................3
      2.2. Message Sending Overview..................................3
      2.3. Traditional Strategy......................................4
      2.4. Forward without download..................................4
      2.5. Additional Considerations.................................6
      2.6. The fcc problem...........................................6
   3. Mobile Optimization............................................7
      3.1. Introduction..............................................7
      3.2. Motivation................................................7
      3.3. The Poll Model vs. the Push Model.........................7
      3.4. Synchronization Techniques................................8
         3.4.1. State-Comparison-Based Synchronization...............9
         3.4.2. Event-based Synchronization.........................10
      3.5. The Server-Side Filtering in Lemonade Profile............11
      3.6. Lemonade Command Extensions..............................11
      3.7. Fast Reconnect...........................................12
      3.8. HTTP Binding.............................................12
      3.9. Revisions to IMAPv4 Rev1 Behavior........................12
   Security Considerations..........................................13
   References.......................................................13
   Acknowledgments..................................................15
   Authors Addresses................................................15
   Intellectual Property Statement..................................15
   Full Copyright Statement.........................................16





Maes                    Expires - January 2005                [Page 2]

                          <Lemonade Profile>                 July 2004


1.  Introduction

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

   This document describes the lemonade profile that includes:
      - The Lemonade Pull Model that describes exchanges between
        Lemonade Agents to allow clients to submit new email messages
        incorporating content which resides on locations external to
        the client.
      - Mobile optimizations that defines extensions to the IMAPv4 Rev1
        protocol [RFC3501] aimed at delivering extended functionality
        for mobile devices with limited resources including support to
        push crucial changes actively to a client, rather then
        requiring the client to initiate contact to ask for state
        changes and extensions for email filter management, message
        delivery, and maintaining up-to-date personal information and
        quick reconnect.

   The organization of this document is as follows.  Section 2 describes
   the Lemonade Pull Model. Section 3 describes the Lemonade Mobile
   Optimizations.

2. The Lemonade Pull Model

2.1. Motivations

   The advent of client/server email using the [RFC3501] and [RFC2821]
   protocols has changed what formerly were local disk operations to
   become excessive and repetitive network data transmissions. This is
   an onerous burden for clients operating over low-bandwidth and/or
   high-latency links.

   The Lemonade Pull Model 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
   SUBMIT servers.

   Pull has the distinct advantage of maintaining one submission
   protocol, and thus avoids the risk of having multiple parallel and
   possible divergent mechanisms for submission.  Furthermore, by
   keeping the details of message submission in the SUBMIT server, the
   Lemonade Pull Model 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



Maes                    Expires - January 2005                [Page 3]

                          <Lemonade Profile>                 July 2004


   The act of sending an email message is best 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 on the MUA.
   Frequently, users choose to save more complex and/or time-consuming
   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 [RFC2476]
   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
   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, once
   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. Forward without download

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

        +--------------------+               +--------------+
        |                    | <------------ |              |
        |     MUA            |               | IMAPv4 Rev1  |


Maes                    Expires - January 2005                [Page 4]

                          <Lemonade Profile>                 July 2004


        |                    |               |  Server      |
        |                    | ------------> | (Server S1)  |
        +--------------------+               +--------------+
               ^  |                             ^     |
               |  |                             |     |
               |  |                             |     |
               |  |                             |     |
               |  |                             |     |
               |  |                             |     |
               |  |                             |     v
               |  |                          +--------------+
               |  |------------------------->|              |
               |                             |   Submit     |
               |-----------------------------|   Server     |
                                             |  (Server S2) |
                                             +--------------+
                     Figure 1: Lemonade Pull Model


   The Lemonade Pull Model 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 server.

   In the [BURL]/[CATENATE] variant of the pull strategy, messages are
   initiated and edited within an MUA.  The [CATENATE] extension to
   [RFC3501] is then used to upload the message to the IMAP server and
   assemble it, and finally a [URLAUTH] format URL is given to a
   [RFC2476] server with the [BURL] extension for submission.

   The flow involved to support such a use case consists of:
      M: {to S1 -- Optional} The client uses IMAP Fetch of body
     structures (See [RFC3501])
      M: {to S1} The client invokes CATENATE (See [CATENATE] for details
     of the semantics and steps û this allows the MUA to create messages
     on the IMAP using new data combined with body structure already
     present on the IMAP server.
      S1: {to M} OK (See [CATENATE]).
      M: {to S1} The client uses GENURLAUTH command to request and
     URLAUTH URL (See [URLAUTH]).
      S1: {to M} The IMAP server returns URLAUTH URL suitable for later
     retrieval with URLFETCH (See [URLAUTH] for details of the semantics
     and steps).
      M: {to S2} The client connects to the submission server and starts
     a new mail transaction. It uses BURL to let the 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 submit server to access the message composed as a
     result of the CATENATE step).



Maes                    Expires - January 2005                [Page 5]

                          <Lemonade Profile>                 July 2004


      S2: {to S1} The submission server uses URLFETCH to fetch 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.).
      S1: {to S2} Provides the message composed as a result of the
     CATENATE step).
      S2: {to M} OK (2XX)

   The messaging user agent, mail server and submit server MUST support
   IMAPv4 Rev1 [RFC3501], CATENATE [CATENATE] and URLAUTH [URLAUTH].

2.5. Additional Considerations

   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 submit [RFC2476] server can
   not access any data on the [RFC3501] server without a "pawn-ticket"
   created by the client.  The "pawn-ticket" grants acces only to the
   specific data that the submit [RFC2476] server is authorized to
   access, can be revoked by the client, and can have a time-limited
   validity.

2.6. The fcc problem

   The "fcc problem" refers to a frequent need to deliver a copy of the
   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
   messages" 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
   "excessive and repetitive network data transmissions" which
   represents the "problem" aspect of the "fcc problem".

   The [CATENATE] extension to [RFC3501] addresses the fcc problem.  It
   requires making several simplifying assumptions:
       (1a) there is one, and only one, fcc destination on a single
   server
       (2a) the server which holds the fcc is the same as the server
   which stages the outgoing message for submission
       (3a) it is desired that the fcc be a copy of the complete message
   text with all external data inserted in the message

   <<[POSTADDRESS] can be used to address issues (1a) and (2a). To be
   done later>>




Maes                    Expires - January 2005                [Page 6]

                          <Lemonade Profile>                 July 2004


3. Mobile Optimization

3.1. Introduction

   The Lemonade profile provides optimizations for the exchanges between
   a mobile client and e-mail server by specifying additional
   enhancements for optimization in a mobile setting.  Thus, the client
   devices in this profile are assumed to be mobile with limited
   resources.  This profile takes into account the limited resources of
   mobile devices, as well as extra functionality desired.

   Figure 2 illustrates the exchanges specified by the mobile
   optimizations of the Lemonade Profile.

   The e-mail server MAY comply with the Lemonade Pull Model described
   in section 2.

        +--------------------+               +--------------+
        |       Mobile       | <------------ |              |
        |     Lemonade       |               |  Lemonade    |
        |   E-mail Client    |               |E-mail Server |
        |                    | ------------> |              |
        +--------------------+               +--------------+
                  Figure 2: Lemonade CS Profile Model

   A disconnected mobile client should behave like a good disconnected
   client [IMAP-DISC].

   Additional requirements for optimization for Mobile access are
   discussed in section 3.6.

3.2. Motivation

   Today, most of the existing email clients have a polling model, where
   the end user is notified of changes to an email account only after
   his/her email client asks the server, called polling.  How long it
   takes a client to learn of a change on the server is thus dependent
   on how often the client polls for changes.  Many clients can poll at
   high rates so that the client can quickly learn of changes and
   reflect them on the client display to achieve a quasi-real time.

   The mobile optimization of the Lemonade profile can support both Poll
   and Push Models.

3.3.  The Poll Model vs. the Push Model

   Today, most of the existing email clients implement a polling model,
   where the end user is notified of changes to an email account only
   after the email client polls the server for changes.  How long it


Maes                    Expires - January 2005                [Page 7]

                          <Lemonade Profile>                 July 2004


   takes a client to learn of a change on the server is thus dependent
   on how often the client polls for changes.  Many clients can poll at
   high rates so that the client can quickly learn of changes and
   reflect them on the client display to achieve a quasi-real time
   synchronization experience for the end user.  The periodic poll model
   is used on conventional email clients.  Because the client must
   continuously poll the server for changes, the bandwidth requirements
   can be quite high and the connection quality must be good in order to
   provide a quasi-real time experience to the user.  This also
   generates additional load on the IMAP server.  The periodic poll
   model is illustrated in Figure 2.

        +--------------------+      Poll     +--------------+
        |                    | <------------ |              |
        |     Mail Server    |               | Email Client |
        |                    | ------------> |              |
        +--------------------+   Response    +--------------+

                     Figure 3: Periodic Poll Model

   Another way to achieve synchronization is for the email server to
   initiate a session with the client when a crucial change to an email
   occurs, which is the push model.  When important events happen to a
   userÆs email account, the server informs the client device about the
   event, and then the client can respond to that event as necessary.
   In this case, the client device does not need to periodically poll
   the mail server, so the push model is particularly effective in the
   mobile computing environment when the cost of constant polling is
   high.  [NOTIFICATIONS] defines the semantics for pushing events to a
   client.  The push model is seen in Figure 2.

        Event   +----------------+    Push    +--------------+
      --------> |   Mail Server  | ---------> | Email Client |
                +----------------+            +--------------+

                          Figure 4: Push Model


3.4.  Synchronization Techniques

   After a client receives a notification that informs it that changes
   have occurred to a mailbox, it needs to employ a synchronization
   technique to reflect the server side changes onto the client device.
   There are many techniques for determining what the changes between a
   server and client are.  In this section, two techniques are presented
   that aim to keep a client device in sync with a given email account,
   meaning that the set of messages on the client device is the same as
   that in the given email account.



Maes                    Expires - January 2005                [Page 8]

                          <Lemonade Profile>                 July 2004


3.4.1. State-Comparison-Based Synchronization

   IMAPv4Rev1 clients use a state-comparison-based synchronization
   technique to be in sync with an email account.  This technique
   requires the client to ask the server for information regarding all
   the folders and all the messages in each folder stored on the server.
   The client must then compute the difference between the server state
   and the client device state, and make all necessary changes so that
   the client device state matches the server state.  An example of the
   interaction between the client and server in the IMAPv4Rev1 protocol
   for performing a state-comparison-based sync follows. This is
   described in more details in [IMAP-DISC].

   First, the client must retrieve the folders from the server. The
   client should issue LIST to figure out which folders has to be
   retrieved. It than uses LSUB to determine which folders are
   subscribed. For example:

      C: A002 LIST "" "%"
      S: * LIST (\NoInferiors) "/" "Drafts"
      S: * LIST () "/" "Friends"
      S: * LIST (\NoInferiors) "/" "INBOX"
      S: A002 OK completed
      C: A003 LSUB "" "*"
      S: * LSUB () "/" "Drafts"
      S: * LSUB () "/" "Friends"
      S: * LSUB () "/" "INBOX"
      S: A003 OK LSUB completed

   Note, that the client should not use LIST "" *, as it might cause too
   much data to be returned. This is discussed in [RFC2683] in more
   details.

   The client must compare its folders with the responses of the command
   above.  If it does not have a folder, it must create that folder on
   the client device.  If there is a folder on the device that is not in
   any of these responses, then the client must delete that folder. In
   order to avoid loosing changes performed on the client, the client
   should apply its changes first. In case when the client has changes
   to a folder that was deleted on the server, it should ask the user
   whether the changes should be uploaded to a different mailbox or be
   discarded (or be configured to automatically do one of the two).

   Next, the client needs to make sure that the emails in each of its
   folders match the server.  It performs a SELECT and then a FETCH
   command for each folder.  A sample of a SELECT and FETCH command for
   the inbox is as follows:
      C: A003 SELECT ôINBOX"
      S: * 60 EXISTS


Maes                    Expires - January 2005                [Page 9]

                          <Lemonade Profile>                 July 2004


      S: ... more untagged responses with information about the folder
      S: A003 OK SELECT completed
      C: A004 FETCH 1:* (FLAGS UID)
      S: * 1 FETCH (FLAGS (\Answered) UID 120)
      S: * 2 FETCH (FLAGS (\Seen) UID 121)
      S: ... flags for messages with message sequence numbers 3-59
      S: * 60 FETCH (FLAGS () UID 250)
      S: A004 OK FETCH completed

   The client must go through the full list of email messages in each
   folder.  It must download an email message from this list if it is
   not already on the client.  Any changes to the mutable flags a
   message must be reflected on the server using IMAP STORE command.
   Also, the client should remove any emails on the client device not in
   this list.  After performing these operations, the client is in sync
   with the server.

   <<Need to check if this matches [IMAP-DISC]>>

3.4.2. Event-based Synchronization

   Another technique is event-based synchronization. Event-based
   synchronization is used to keep the client device in sync with the
   server. This method requires that the client has been fully
   synchronized with the server at some earlier point.  In the
   IMAPv4Rev1 protocol, the client must perform a state-comparison-based
   sync when it selects a folder, but then it can use event-based
   synchronization to keep itself in sync after that.  Although event-
   based synchronization cannot totally replace state-comparison-based
   synchronization, it is a faster alternative for the client to
   maintain synchrony when the server is capable of change tracking for
   a client.

   In event-based synchronization, the server keeps track of what
   changes have occurred to the email account that are not yet reflected
   on the client device.   Such a change is called an event.  When the
   client finishes processing all events since the last time it was in
   sync with the server, it is again in sync with the server.  Event-
   based synchronization is particularly effective when the server can
   push events to the client for immediate processing.  In this case,
   there are likely to be only a small number of events the client needs
   to process at one time.

   Also, when a Lemonade client drops a connection or accidentally
   disconnects the server can retain the session and cache all events
   during the time the client is disconnected.  When the client
   reconnects it does not need to perform a state-comparison-based
   synchronization all over again, and the server sends the list of
   pending events to the client..


Maes                    Expires - January 2005               [Page 10]

                          <Lemonade Profile>                 July 2004



   Lemonade Mobile Clients and Servers MUST support Lemonade Server to
   Client Notifications as described in [NOTIFICATIONS].


3.5. The Server-Side Filtering in Lemonade Profile

   The Lemonade server MUST support Server-side filtering as described
   in [NOTIFICATIONS].

3.6.  Lemonade Command Extensions

   The Lemonade server MUST support the rich set of extra functionality
   over the IMAP server to support extra features for a mobile client
   described as Lemonade Command Extensions in [EXTENSIONS]. These
   include:

     [1] Compression û Lemonade CS Profile allows for compression of
     responses to a command.  Preliminary testing results shows
     significant performance results when the response to FETCH FLAGS or
     header information are compressed. Details are found in
     [EXTENSIONS].

     [2] Sending emails - The Lemonade server can be used to send email,
     thus eliminating the need for the Lemonade client to connect to a
     separate SMTP server. When interfacing with a server that supports
     LEMONADEDELIVER as discovered via CAPABILITY commands as described
     in [Extensions], this is the mechanism that SHOULD be used.
     Otherwise, the client is expected to implement the Lemonade Pull
     Model described in section 2.

     [3] Support for unstable mobile connections û After a client drops
     a connection, the Lemonade server can temporarily maintain the
     session for the mobile client.  During this time, the server caches
     any events concerning the mobile repository while the client is
     disconnected, which it can then send to the client upon
     reconnection.  This is described in more details in Section 3.7 of
     this document.

     [4] Longer periods of inactivity tolerated - A Lemonade server
     should wait at least 24 hours before logging out an inactive mobile
     client and ending its session. <<This may lead to Deny of Service.
     To be investigated.>>

     [5] Attachments forward/reply behavior - When forwarding/replying
     to a message from the Lemonade client, the end user may choose to
     reattach the original's message attachments by just specifying the
     UID of the original message and specifiers for the required
     bodyparts.  The client need not download the attachments of the


Maes                    Expires - January 2005               [Page 11]

                          <Lemonade Profile>                 July 2004


     original message itself. This is an expected server behavior. It
     MAY also be implemented following the Lemonade Pull Model.

     [6] Attachments conversion - The Lemonade server can convert
     attachments to other formats to be viewed on a mobile device. This
     is an expected server behavior.

     [7] PIM - The protocol also provides support for updating personal
     information on a client device, even when these changes are
     initiated from another client (i.e. a personal assistant connects
     to an end userÆs account from a desktop and changes contact
     information.)  These additional uses are especially useful for
     mobile devices, where end users need up-to-date information on the
     fly. <<This requires additional work to store calendaring and
     address book informations.>>

3.7. Fast Reconnect

   Mobile operators usually charge users for the time their mobile
   client gets connected to the Internet and/or for the amount of
   information sent/received. Thus a mobile client should minimize time
   it stays connected to its mail server, which suggests that it should
   disconnect and reconnect frequently.

   Also, it is possible that the mobile client unexpectedly leaves area
   of connectivity, which will require that the client reconnects when
   connectivity returns.

   IMAP can be verbose. Usually, in order to synchronize a client with a
   server after a disconnect, the client needs to issue at least the
   following commands: LOGIN/AUTHENTICATE, SELECT and several FETCH
   commands (see [IMAP-DISC] for more details).

   Thus, there is a desire to have a quick reconnect facility in IMAP,
   which will give a mobile client ability to resume a previously
   abandoned session, without the need to perform the full
   synchronization sequence as described above.

   <<Note, we need an example here with and without the extension. To Be
   Done.>>

3.8. HTTP Binding

   For mobile clients, the Lemonade Profile exchanges MAY be transported
   on HTTP as described in [HTTPBINDINGS].


3.9.  Revisions to IMAPv4 Rev1 Behavior



Maes                    Expires - January 2005               [Page 12]

                          <Lemonade Profile>                 July 2004


   A Lemonade server MUST responds to all IMAPv4Rev1 commands.  A
   compliant Lemonade server must implement all the commands in IMAPv4
   Rev1, with the revisions described in [NOTIFICATIONS] and
   [EXTENSIONS].


Security Considerations

   Security considerations on the Lemonade Pull Model are discussed
   throughout section 2.

   The mobile optimization of the Lemonade profile calls for the same
   security requirements for an in-response and inband connectivity mode
   as IMAP.

   For the outband connectivity mode, servers should use encryption
   methods for notifications if sensitive information is included in the
   payload of that notification.

   When an implementation of Lemonade Mobile Profile is proxy-based,
   this may create new security issues.  These issues are discussed in
   detail in [EXTENSIONS], because the issues are dependent on the
   implementation of this protocol rather than inherent to the protocol
   itself.

References

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

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

   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate
      Requirement Levels", RFC 2119, March 1997.
      http://www.ietf.org/rfc/rfc2119

   [RFC2180] Gahrns, M.  "IMAP4 Multi-Accessed Mailbox Practice", RFC
      2180, July 1997.
      http://www.ietf.org/rfc/rfc2180

   [RFC2234] Crocker, D. and Overell, P.  "Augmented BNF for Syntax
      Specifications", RFC 2234, Nov 1997.
      http://www.ietf.org/rfc/rfc2234





Maes                    Expires - January 2005               [Page 13]

                          <Lemonade Profile>                 July 2004


   [RFC2420] Kummert, H.  "The PPP Triple-DES Encryption Protocol
      (3DESE)", RFC 2420, September 1998.
      http://www.ietf.org/rfc/rfc2420

   [RFC2616] Fielding, R. et al.  "Hypertext Transfer Protocol --
      HTTP/1.1", RFC 2616, June 1999.
      http://www.ietf.org/rfc/rfc2616

   [RFC2617] Franks, J. et al.  "HTTP Authentication: Basic and Digest
      Access Authentication", RFC 2617, June 1999.
      http://www.ietf.org/rfc/rfc2617

   [RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683
      Sep 1999.
      http://www.ietf.org/rfc/rfc2683

   [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997.
      http://www.ietf.org/rfc/rfc2177

   [RFC2818] Rescorla, E. "HTTP over TLS", RFC 2818, May 2000.
      http://www.ietf.org/rfc/rfc2818

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

   [RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April
      2001.  http://www.ietf.org/rfc/rfc2822

   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
      Version 4 rev1", RFC 3501, March 2003.
      http://www.ietf.org/rfc/rfc3501

   [RFC2476] Gellens, R. and Klensin, J., "Message Submission", RFC
      2476, December 1998.

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

   [BURL]    Newman, C., "Message Composition", draft-newman-lemonade-
      compose-00.txt (work in progress), June 2003.

   [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access
      Protocol (IMAP) - URLAUTH Extension", draft-crispin-imap-urlauth-
      09.txt, (work in progress), July 2004.

   [EXTENSIONS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
      Chiu, E., "Lemonade Command Extensions", draft-maes-lemonade-
      command-extensions-00.txt, (work in progress), July 2004.


Maes                    Expires - January 2005               [Page 14]

                          <Lemonade Profile>                 July 2004



   [NOTIFICATIONS] Maes, S.H. and Wilson C., "Lemonade Server to Client
      Notifications", draft-ietf-lemonade-server-to-client-
      notifications-00.txt, (work in progress), July 2004.

   [HTTPBINDINGS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V.
      and Chiu, E., "Lemonade HTTP Binding", draft-maes-lemonade-http-
      binding-00.txt, (work in progress), July 2004.

   [POSTADDRESS] Melnikov, A., "IMAP4 POSTADDRESS extension", work in
      progress, draft-melnikov-imap-postaddress-XX.txt

Acknowledgments

   This document is based on the work in progress described in draft-
   crispin-lemonade-pull-01.txt and draft-maes-lemonade-p-imap-03.txt.

Authors Addresses

   Stephane H. Maes
   Oracle Corporation
   500 Oracle Parkway
   M/S 4op634
   Redwood Shores, CA 94065
   USA
   Phone: +1-650-607-6296
   Email: stephane.maes@oracle.com

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex
   TW12 2BX
   UK
   Email: Alexey.melnikov@isode.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to


Maes                    Expires - January 2005               [Page 15]

                          <Lemonade Profile>                 July 2004


   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Acknowledgement

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


Full Copyright Statement

   Copyright (C) The Internet Society 2003.  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.








Maes                    Expires - January 2005               [Page 16]


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