view Side-By-Side changes

 
 
Lemonade                                                                
Internet Draft: Lemonade Profile                             S. H. Maes 
Document: draft-ietf-lemonade-profile-02.txt draft-ietf-lemonade-profile-03.txt                A. Melnikov 
Expires: October 2005                                        April January 2006                                         July 2005 
    
    
                             Lemonade Profile 
    
Status of this Memo 
 
   This document is an Internet-Draft and is subject to all provisions 
   of Section 10 of RFC2026. 
 
   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 become becomes 
   aware will be disclosed, in accordance with 
   RFC 3668. 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 mail protocols such as the IMAP and 
   Submission. 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 various IMAP and Mail 
   Submission protocols; specifically URLAUTH, CATENATE, Lemonade Command Extensions in the URLAUTH and CATENATE IMAP protocol 
   [RFC3501] extensions and BURL in extension to the SUBMIT protocol 
   [RFC2476]. 
 

 
 
Maes                    Expires - October 2005 January 2006                [Page 1] 





                          <Lemonade Profile>               April                 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 Memo...............................................1 
   Abstract..........................................................1 
   Conventions used in this document........................... 2 document.................................2 
   Table of Contents........................................... 2 Contents.................................................2 
   1. Introduction............................................. 3 Introduction...................................................3 
   2. Forward without download ................................ 3 download.......................................3 
      2.1. Motivations ........................................ 3 Motivations...............................................3 
      2.2. Message Sending Overview............................ 3 Overview..................................3 
      2.3. Traditional Strategy................................ 4 Strategy......................................4 
      2.4. Step by step description............................ 5 description..................................5 
      2.5. Normative statements related to forward without 
	   download ........................................... 8 download..8 
      2.6. Additional Considerations........................... 8 Considerations.................................9 
      2.7. The fcc problem..................................... 9 problem...........................................9 
   3. Message Submission....................................... 9 Submission.............................................9 
      3.1. Future Delivery..................................... 9 Delivery..........................................10 
      3.2. Pipelining..........................................10 Pipelining...............................................10 
      3.3. TLS.................................................10 TLS......................................................10 
      3.4. DSN Support ........................................11 Support..............................................11 
      3.5. Message size declaration............................11 declaration.................................11 
      3.6. Enhanced status code Support.............................11 
   4. Quick Reconnect scheme...................................11 scheme........................................11 
      4.1. Normative statements related to quick reconnect 
	   schemes ........................................... 12 schemes..12 
   5. Future work............................................. 12 work...................................................13 
   6. Security Considerations.................................... 13 Considerations.......................................13 
   7. IANA Considerations ....................................... 13 
   References................................................. 13 Considerations...........................................13 
   8. References....................................................13 
      8.1. Normative References.....................................13 
      8.2. Informative References...................................14 
   Version History............................................ 14 
   Acknowledgments............................................ 15 History..................................................15 
   Acknowledgments..................................................15 
   Authors Addresses.......................................... 15 Addresses................................................16 
   Intellectual Property Statement............................ 15 
   Full Copyright Statement................................... 16 Statement..................................16 
    
 
 
Maes                    Expires - October 2005 January 2006                [Page 2] 





                          <Lemonade Profile>               April                 July 2005 
 
 
    
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 "Forward without download" that describes exchanges between 
        Lemonade Agents clients and servers to allow clients to submit new email 
        messages incorporating content which resides on locations 
        external to the client and allow forward without download. client. 
      - Media conversion 
      - Quick reconnect   
    
   The organization of this document is as follows.  Section 2 describes 
   the Lemonade Pull Model. Section 3 Forward without download. Section 3 describes the Media 
   Conversion. additional SMTP 
   extensions that must be supported by all Lemonade Submission servers. 
   Section 4 describes quick reconnect reconnect.  
    
2.   Forward without download 
    
2.1.     Motivations 
    
   The advent of client/server email using the [RFC3501] and [RFC3501], [RFC2821] and 
   [RFC2476] protocols has changed what formerly were local disk 
   operations to become excessive and repetitive network data 
   transmissions.  
    
   The  
    
   Lemonade Pull Model "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. 
    
   Pull 
    
   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, the Lemonade 
   Pull Model "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 is best 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. 
 
 
Maes                    Expires - October 2005               [Page 3] 

                          <Lemonade Profile>               April 2005 
    
   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 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 - October 2005 January 2006                [Page 4] 




                          <Lemonade Profile>               April                 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 Pull Model 
             
    
   The "forward without download" 
             
    
   Lemonade Pull Model "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 pull Lemonade "forward without 
   download" strategy, messages are initially composed and edited within 
   an MUA.  The [CATENATE] extension to [RFC3501] is then used to upload create 
   the message to 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 connectects connects to the IMAP server server, 
     opens a mailbox ("INBOX" in the example below) and IMAP Fetch of fetches body 
     structures and UIDs (See [RFC3501]) [RFC3501]). 
      
     Example: 
           M: A0051 UID FETCH 161 25627 (UID BODYSTRUCTURE) 
 
 
Maes                    Expires - October 2005               [Page 5] 




                          <Lemonade Profile>               April 2005 
           I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 
              ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" 23)( 
              "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 
              "cc.diff")  
              "trip.txt")  
              "<960723163407.20117h@washington.example.net>" "Compiler 
     diff" 
              "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 body structure one or more message part 
     already present on the IMAP server. 
      
     <<EditorÆs 
      
     <<Editor's note: Draft editing/catenation is omitted for now>> 
      
        M: A0052 CATENATE APPEND Sent FLAGS (\Seen $MDNSent) TEXT 
           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 "imap://imap.example.org/INBOX;UIDVALIDITY=385759045/; 
           UID=25627;Section=1.2" " /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 
 
 
Maes                    Expires - October 2005               [Page 6] 





                          <Lemonade Profile>               April 2005 
        M: A0053 UID STORE XXX 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 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 and 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/;urla
     uth=submit+bar" "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/;urla
     uth=submit+bar:internal:91354a473744909de610943775f92038" "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 SMTP 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/;urlau
     th=submit+bar:internal:91354a473744909de610943775f92038 imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/; 
           uid=45/;urlauth=submit+bar:internal: 
           91354a473744909de610943775f92038 LAST 
      
      S: {to I} The SMTP 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.). 
 
 
Maes                    Expires - October 2005               [Page 7] 





                          <Lemonade Profile>               April 2005 
      I: {to S} Provides the message composed as a result of the 
     CATENATE step). 
      
     SMTP 
      
     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/;urlau
     th=submit+bar:internal:91354a473744909de610943775f92038" "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/;urlau
     th=submit+bar:internal:91354a473744909de610943775f92038" "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 
      
     << EditorÆs note: The SMTP submission server may LOGOUT>> 
        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 mail server IMAP servers MUST therefore respectively support IMAPv4 Rev1 [RFC3501], 
   CATENATE [CATENATE] and URLAUTH [URLAUTH]. Its This support MUST be 
   declared via CAPABILITY [RFC3501]. 
    
   Lemonade compliant SMTP submit servers MUST support the BURL extensions [BURL]. Its 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. 
 
 
Maes                    Expires - October 2005               [Page 8] 



                          <Lemonade Profile>               April 2005 
    
    
2.7.     The fcc problem 
    
   The "fcc problem" refers to a frequent need to deliver delivering a copy of the 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 Editor's note: [POSTADDRESS] can be used to address issues (1a) 
   and (2a). To be done later>> 
    
    
3.   Message Submission 
    
   LEMONADE compliant SMTP mail submission server servers are expected to implement a 
   the following set of SMTP extensions to make message submission 
   efficient.  The  Lemonade clients SHOULD take advantage of these features. 
    
 
 
 
Maes                    Expires - January 2006                [Page 9] 


                          <Lemonade Profile>                 July 2005 
 
 
3.1.     Future Delivery 
    
   Diverse devices may suffer from intermittent or unpredictable 
   connectivity.  Although this does not address the main issues of 
   intermittent connectivity, it may be of interest 
    
   Users often wish to email users compose a message, which is to be 
   able to take advantage of future delivery by marking ahead of time delivered at a 
   message for 
   future submission into point.  For example, a birthday greeting may be composed when 
   the mail system. user thinks of it, but be held until the actual date.  
    
   For well-connected devices, the client can hold a message in the 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 SMTP mail submission servers MUST MAY declare via ELHO 
   [RFC2821] the support the SMTP service extension for future delivery.   
 
 
Maes                    Expires - October 2005               [Page 9] 


                          <Lemonade Profile>               April 2005   
    
   If future delivery is not permitted by policy, the server MAY not 
   support (and declare) support for future delivery or the SMTP mail 
   submission server may MAY advertise a future delivery interval of zero 
   seconds. 
    
   <<EditorÆs  
    
   <<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 lemonade SMTP mail submission server 
   supports the SMTP service extension for future deliver delivery [Future 
   delivery].   
    
   When dealing with an device that support future delivery, such 
   clients may   
    
   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 servers and clients should use SMTP command 
   pipelining for message submission. LEMONADE compliant SMTP 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 SMTP mail Submission, a 
   protocol that requires sending a URLAUTH token to the SMTP 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 SMTP mail submission path will 
   provide protection against this attack. 
    
   LEMONADE Compliant SMTP mail submission servers MUST support SMTP Service 
   Extension for Secure SMTP over TLS [RFC2487] supporting at least SASL 
   PLAIN [RFC2595] authentication.   
    


 
 
Maes                    Expires - October 2005              [Page 10] 



                          <Lemonade Profile>               April 2005 
 
 
   LEMONADE [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 SMTP 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 
    
   It is expected that a LEMONADE compliant SMTP submission servers 
   supports delivery status notifications. 
    
    
   LEMONADE compliant SMTP mail submission servers MUST support SMTP service 
   extensions for delivery status notifications [RFC3461] and enhanced 
   status codes.   
    
   <<EditorÆs note: Enhanced status code may lead to a separate 
   section>> [RFC3461]. 
    
    
3.5.     Message size declaration 
    
   LEMONADE compliant SMTP 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 gets is connected to the Internet and/or for the amount of 
   information sent/received. Thus a mobile client should 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 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. 
    
 
 
Maes                    Expires - October 2005              [Page 11] 


                          <Lemonade Profile>               April 2005 
    
    
   << EditorÆs 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 form from mobile devices, possibly 
   including: 
      - Address editorÆs notes 
      - 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 
 
 
Maes                    Expires - October 2005              [Page 12] 



                          <Lemonade Profile>               April 2005 
      - filtering  
      - Other considerations for mobile clients 
    
6.   Security Considerations 
    
   Security considerations on the Lemonade Pull Model "forward without download" are 
   discussed throughout section 2. 
    
   << EditorÆs Editor's note: TBD (Reconnect, etc.)>> 
    
7.   IANA Considerations 
    
   Lemonade profile extensions should be appropriately related to the 
   list of IMAP and SMTP parameters. 
    
   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, 
    
   [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 
    
   [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 
    
   [RFC2197] Freed, N. "SMTP Service Extension for Command Pipelining", 
      RFC 2197, September 1997. http://www.ietf.org/rfc/rfc2197  
    
 
 
Maes                    Expires - October 2005              [Page 13] 





                          <Lemonade Profile>               April 2005 
 
 
    
   [RFC2234] Crocker, D. and Overell, P.  "Augmented BNF for Syntax 
      Specifications", RFC 2234, Nov 1997.  
      http://www.ietf.org/rfc/rfc2234  
    
    
   [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   
    
   [RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683 
      Sep 1999. 
      http://www.ietf.org/rfc/rfc2683   
    
   [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 
   [RFC3461] Gellens, R. and Klensin, J., 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). 
    
    
Version History 
     
   Version 02: 
   [1] Improved abstract based on review comments as well as change 
    
   [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. 
 
 
Maes                    Expires - October 2005              [Page 14] 





                          <Lemonade Profile>               April 2005 
   [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 "status of this memoö memo" 
      and ôCopyrightö. "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 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
 
 
Maes                    Expires - October 2005              [Page 15] 





                          <Lemonade Profile>               April 2005 
   this document or the extent to which any license under such rights 
   might or might not be available; neither nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation RFC documents can be 
   found in BCP-11. BCP 78 and BCP 79. 
    
   Copies of 
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this 
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement 
   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) at ietf-
   ipr@ietf.org. 
    
   The Internet Society 2004. This document is subject IETF has been notified of intellectual property rights claimed in 
   regard to some or all of the rights, licenses and restrictions specification contained in BCP 78, and except 
   as set forth therein, this 
   document.  For more information consult the authors retain all their 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 and translations of it may be copied and furnished is subject 
   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 rights, licenses and derivative works.  However, this 
   document itself may not be modified restrictions contained in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, BCP 78, and 
   except as needed for the purpose of 
   developing Internet standards in which case set forth therein, the procedures authors retain all their rights. 
    
Acknowledgement 
    
   Funding for 
   copyrights defined in the Internet Standards process must be 

 
 
Maes                    Expires - October 2005              [Page 16] 





                          <Lemonade Profile>               April 2005 
 
 
   followed, or as required to translate it into languages other than 
   English.  
            
   The limited permissions granted above are perpetual and will not be  
   revoked RFC Editor function is currently provided by the 
   Internet Society or its successors or assigns. Society. 
    
    
 

























 
 
Maes                    Expires - October 2005 January 2006               [Page 17] 










----