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

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

                          <Lemonade Profile>                 July 2005


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


                             Lemonade Profile

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.

Abstract

   This document describes a profile (a set of required extensions,
   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 schedule future delivery of a
   message, to optimize submission and to efficiently reconnect 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
   [RFC2476].




Maes                    Expires - January 2006                [Page 1]

                          <Lemonade Profile>                 July 2005


   In addition, the Lemonade profile contains Lemonade Command
   extensions for quick reconnect and media conversion.

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 [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. Forward without download.......................................3
      2.1. Motivations...............................................3
      2.2. Message Sending Overview..................................3
      2.3. Traditional Strategy......................................4
      2.4. Step by step description..................................5
      2.5. Normative statements related to forward without download..8
      2.6. Additional Considerations.................................9
      2.7. The fcc problem...........................................9
   3. Message Submission.............................................9
      3.1. Future Delivery..........................................10
      3.2. Pipelining...............................................10
      3.3. TLS......................................................10
      3.4. DSN Support..............................................11
      3.5. Message size declaration.................................11
      3.6. Enhanced status code Support.............................11
   4. Quick Reconnect scheme........................................11
      4.1. Normative statements related to quick reconnect schemes..12
   5. Future work...................................................13
   6. Security Considerations.......................................13
   7. IANA Considerations...........................................13
   8. References....................................................13
      8.1. Normative References.....................................13
      8.2. Informative References...................................14
   Version History..................................................15
   Acknowledgments..................................................15
   Authors Addresses................................................16
   Intellectual Property Statement..................................16



Maes                    Expires - January 2006                [Page 2]

                          <Lemonade Profile>                 July 2005



1.    Introduction

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

   This document describes the lemonade profile that includes:
      - "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.
      - Media conversion
      - Quick reconnect

   The organization of this document is as follows.  Section 2 describes
   the Forward without download. Section 3 describes additional SMTP
   extensions that must be supported by all Lemonade Submission servers.
   Section 4 describes quick reconnect.

2.   Forward without download

2.1.     Motivations

   The advent of client/server email using the [RFC3501], [RFC2821] and
   [RFC2476] protocols has changed what formerly were local disk
   operations to become excessive and 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 possible divergent mechanisms for submission. The
   client can use Submit/SMTP [RFC2476] 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.


Maes                    Expires - January 2006                [Page 3]

                          <Lemonade Profile>                 July 2005



   Initiation of a new draft and draft editing takes place on 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 [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, 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.
















Maes                    Expires - January 2006                [Page 4]

                          <Lemonade Profile>                 July 2005












2.4.     Step by step description

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

        +--------------------+               +--------------+
        |                    | <------------ |              |
        |     MUA (M)        |               | IMAPv4 Rev1  |
        |                    |               |  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
   server.

   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 message on the IMAP server by transmitting new text and assemble
   it, and finally a [URLAUTH] format URL is given to a [RFC2476] server
   with the [BURL] extension for submission.


Maes                    Expires - January 2006                [Page 5]

                          <Lemonade Profile>                 July 2005



   The flow involved to support such a use case consists of:
      M: {to I -- Optional} The client connects to the IMAP server,
     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.net>"
              "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 using new data combined with one or more message part
     already present on the IMAP server.

     <<Editor's note: Draft editing/catenation is omitted for now>>

        M: A0052 APPEND Sent FLAGS (\Seen $MDNSent)
           CATENATE (TEXT {738}
        I: + Ready for literal data
        M: Return-Path: <bar@example.org>
        M: Received: from [127.0.0.2]
        M:           by rufus.example.org via TCP (internal) with
     ESMTPA;
        M:           Thu, 11 Nov 2004 16:57:07 +0000
        M: Message-ID: <419399E1.6000505@example.org>
        M: Date: Thu, 12 Nov 2004 16:57:05 +0000
        M: From: Bob Ar <bar@example.org>
        M: X-Accept-Language: en-us, en
        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; charset=us-ascii; format=flowed
        M: Content-Transfer-Encoding: 7bit
        M:
        M: Our travel agent has sent the updated schedule.
        M:
        M: Cheers,
        M: Bob


Maes                    Expires - January 2006                [Page 6]

                          <Lemonade Profile>                 July 2005


        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: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
        I: A0053 OK STORE completed

     <<Editor's note: UID STORE will only work if the marked message is
     in the currently selected mailbox>>
     << Editor's note: Recommend UIDPLUS extension - especially useful
     when appending messages to a non-selected mailbox>>

      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/;urlauth=submit+bob.ar"
           INTERNAL
        I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
           UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
           internal:91354a473744909de610943775f92038"
        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 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).

     M: EHLO potter.example.org
        S: 250-owlry.example.com
        S: 250-8BITMIME
        S: 250-BURL imap
        S: 250-AUTH PLAIN
        S: 250-DSN
        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.


Maes                    Expires - January 2006                [Page 7]

                          <Lemonade Profile>                 July 2005


        M: RCPT TO:<ron@gryffindor.example.com>
        S: 250 2.1.5 ron@gryffindor.example.com 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
     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 URLAUTH] example.com
           IMAP server ready
        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

     S2: {to M} OK (2XX)

     Submission server returns OK to the MUA:
        S: 250 2.5.0 Ok.


2.5.     Normative statements related to forward without download

   Lemonade compliant IMAP servers MUST support IMAPv4 Rev1 [RFC3501],
   CATENATE [CATENATE] and URLAUTH [URLAUTH]. This support MUST be
   declared via CAPABILITY [RFC3501].

   Lemonade compliant submit servers MUST support the BURL [BURL]. This
   support MUST be declared via EHLO [RFC2821].

   A Lemonade client SHOULD support IMAPv4 Rev1 [RFC3501], CATENATE
   [CATENATE], BURL extensions [BURL] and URLAUTH [URLAUTH].



Maes                    Expires - January 2006                [Page 8]

                          <Lemonade Profile>                 July 2005


   Additional normative statements are provided in other sections.


2.6.     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 SMTP 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 SMTP submit [RFC2476] 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 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

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


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.




Maes                    Expires - January 2006                [Page 9]

                          <Lemonade Profile>                 July 2005


3.1.     Future Delivery

   Users often wish to compose a message, which is to be delivered at a
   future point.  For example, a birthday greeting may be composed when
   the user thinks of it, but be held until the actual date.

   For well-connected devices, the client can hold a message in a
   conceptual "outbox" until an appointed time, and then release the
   message.  Otherwise, the client may need to rely upon a well-
   connected server for this function.

   LEMONADE compliant mail submission servers MAY declare via ELHO
   [RFC2821] the support the SMTP service extension for future delivery.

   If future delivery is not permitted by policy, the server MAY not
   support (and declare) support for future delivery or the mail
   submission server MAY advertise a future delivery interval of zero
   seconds.

   <<Editor's note: The latest version of FUTUREDELIVERY doesn't allow a
   compliant server to advertise the interval of 0. This should be
   addressed or remove here >>

   LEMONADE clients requiring the ability to reliably send future
   delivery messages can discover via EHLO if a mail submission server
   supports the SMTP service extension for future delivery [Future
   delivery].

   Clients MAY cache or otherwise remember the advertised future
   delivery interval from a previous submission transaction to guide the
   human user into the selection of a valid future delivery interval.


3.2.     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. [REF2197]

   Clients SHOULD pipeline.

3.3.     TLS

   LEMONADE clients may use the BURL extension to mail Submission, a
   protocol 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 will disclose the contents of the message to an


Maes                    Expires - January 2006               [Page 10]

                          <Lemonade Profile>                 July 2005


   attacker.  TLS based encryption of the mail submission path will
   provide protection against this attack.

   LEMONADE Compliant mail submission servers MUST support SMTP Service
   Extension for Secure SMTP over TLS [RFC2487]. << Editor's note:
   discussion about authentication should be a separate section? >>

   LEMONADE Compliant IMAP servers MUST support IMAP over TLS [RFC3501]
   as required by IMAP4rev1. << Editor's note: delete or keep? Already
   required by RFC 3501 >>

   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 server SHOULD use TLS protected
   IMAP when fetching message content using the URLAUTH token provided
   by the LEMONADE client.


3.4.     DSN Support


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


3.5.     Message size declaration

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

3.6.     Enhanced status code Support

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


4.   Quick Reconnect scheme

   Mobile operators usually charge users for the time their mobile
   client is connected to the Internet and/or for the amount of
   information sent/received. Thus a mobile client might want to
   minimize the 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 an
   area of connectivity, which will require that the client reconnects
   when connectivity returns.


Maes                    Expires - January 2006               [Page 11]

                          <Lemonade Profile>                 July 2005



   << Editor's note: Discussion about voluntarily versa non-voluntarily
   disconnects might go here>>

   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 the ability to resume a previously
   abandoned session, without the need to perform the full
   synchronization sequence as described above.


   << Editor's note: Example is as per reconnect-02, syntax is subject
   to change>>

      S: * OK [CAPABILITY IMAP4REV1 STARTTLS AUTH=LOGIN CONDSTORE
         X-DRAFT-W02-RECONNECT] imap.example.com IMAP4rev1 2001.315rh
         at Thu, 15 Jul 2004 11:47:49 -0400 (EDT)
      C: b0002 authenticate login (SID P1234567890 56789
   20010715194045000
      41,43:211,214:541)
      S: + VXNlciBOYW1lAA==
      C: dGVzdDg=
      S: + UGFzc3dvcmQA
      C: dGVzdDg=
      S: * FOLDER INBOX
      S: * 464 EXISTS
      S: * 3 RECENT
      S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
      S: * OK [UIDNEXT 550] Predicted next UID
      S: * OK [HIGHESTMODSEQ 20010715194045007]
      S: * 1 FETCH (UID 1 FLAGS (\Seen))
      S: b0002 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS
   SCAN
      SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User
      test8 authenticated

4.1.     Normative statements related to quick reconnect schemes

   Lemonade compliant mail server MUST support the quick reconnect
   scheme described above.

   A Lemonade client SHOULD support the quick reconnect scheme described
   above.




Maes                    Expires - January 2006               [Page 12]
                          <Lemonade Profile>                 July 2005


5.   Future work

   Future versions of the Lemonade profile are expected to address
   issues related to access of email from mobile devices, possibly
   including:
      - Recommendations in terms of support of Binary and 8-bit MIME
        Transport
      - Media conversion (static and streamed)
      - transport optimization for low or costly bandwidth and less
        reliable mobile networks
      - server to client notifications outside of the traditional IMAP
        band
      - dealing with firewall and intermediaries
      - compression
      - filtering
      - Other considerations for mobile clients

6.   Security Considerations

   Security considerations on Lemonade "forward without download" are
   discussed throughout section 2.

   << Editor's note: TBD (Reconnect, etc.)>>

7.   IANA Considerations

   This document doesn't require any IANA registration or action.


8.   References

8.1.     Normative References

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

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

   [Future delivery] White, G. and Vaudreuil, G. "SMTP Submission
      Service Extension for Future Delivery", work in progress, draft-
      ietf-lemonade-futuredelivery-XX.txt

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






Maes                    Expires - January 2006               [Page 13]
                          <Lemonade Profile>                 July 2005


   [RECONNECT] Melnikov, A. and C. Wilson " IMAP4 extension for quick
      reconnect ", work in progress, draft-ietf-lemonade-reconnect-
      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

   [RFC2197] Freed, N. "SMTP Service Extension for Command Pipelining",
      RFC 2197, September 1997. http://www.ietf.org/rfc/rfc2197


   [RFC2476] Gellens, R. and Klensin, J., "Message Submission", RFC
      2476, December 1998. http://www.ietf.org/rfc/rfc2476

   [RFC2487] Hoffman, P. "SMTP Service Extension for Secure SMTP over
      TLS ", RFC 2487, Jan 1999.  http://www.ietf.org/rfc/rfc2487

   [RFC2595] Newman, C. "Using TLS with IMAP, POP3 and ACAP ", RFC
      22595, Jun 1999.  http://www.ietf.org/rfc/rfc2585

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

[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4
rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501
   [RFC3461] Moore, K., , "Simple Mail Transfer Protocol (SMTP) Service
      Extension for Delivery Status Notifications (DSNs)", RFC 3461,
      January 2003. http://www.ietf.org/rfc/rfc3461

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

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

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



8.2.     Informative References

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


Maes                    Expires - January 2006               [Page 14]
                          <Lemonade Profile>                 July 2005




Version History

   This section will be deleted before publication.

   Version 03:
   [1] Updated boilerplate.
   [2] Addressed most of the comments raised by Randy Gellens and some
   from Pete Resnick.
   [3] Purged and updated references.
   [4] Updated examples as per changes in CATENATE and other documents.
   [5] Replaced Lemonade Pull model by Lemonade "forward without
   download".
   [6] Qualified normative statement on future delivery.

   Version 02:
   [1] Improved abstract based on review comments as well as change to
   reflect the re-organized content of the present Lemonade profile.
   [2] Editorial improvement of section 2.1
   [3] Addition of section 2.5 with normative statements for lemonade
   compliant clients and servers regarding forward without download.
   [4] Addition of section 3 on message submission.
   [5] Move of media conversion to future work
   [6] Add section 4.1 on normative statements related to quick
   reconnect scheme.
   [6] Addition of Binary and 8-bit MIME Transport to future work
   [7] Addition of IANA statement
   [8] Update and fix of the references


   Version 01:
   [1] We removed the sections of the profile related to mobile e-mail
      as well as discussion. This will be part of the next version of
      the Lemonade profile work.
   [2] We added detailed examples for the different steps included in

      section 2.4.
   [3] We added section 3 on media conversion
   [4] We added examples on Quick reconnect schemes in section 4.
   [5] We updated the security considerations
   [6] We fixed references based on updates above
   [7] We added a future work section
   [8] We fixed the boiler plate statements on the "status of this memo"
      and "Copyright".

Acknowledgments

   This document is based on the work in progress described in draft-
   crispin-lemonade-pull-xx.txt.


Maes                    Expires - January 2006               [Page 15]
                          <Lemonade Profile>                 July 2005



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

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


Maes                    Expires - January 2006               [Page 16]
                          <Lemonade Profile>                 July 2005



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 (2005).  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.

Acknowledgement

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






























Maes                    Expires - January 2006               [Page 17]


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