<Lemonade Profile> September 2005 Lemonade Internet Draft: Lemonade Profile S. H. Maes Document: draft-ietf-lemonade-profile-04.txt A. Melnikov Expires: March 2006 September 2005 Lemonade Profile - Phase 1 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 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 - March 2006 [Page 1]
<Lemonade Profile> September 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. Security Considerations for pawn-tickets..................9 2.7. The fcc problem...........................................9 3. Message Submission.............................................9 3.1. Pipelining...............................................10 3.2. DSN Support..............................................10 3.3. Message size declaration.................................10 3.4. Enhanced status code Support.............................10 4. Quick Reconnect scheme........................................10 4.1. Normative statements related to quick reconnect schemes..11 5. Additional IMAP extensions....................................11 6. Summary of IMAP and SMTP extensions required for phase 1......11 7. Future work...................................................12 8. Security Considerations.......................................13 8.1. TLS......................................................13 9. IANA Considerations...........................................13 10. References...................................................13 10.1. Normative References....................................13 10.2. Informative References..................................15 Open issues......................................................15 Version History..................................................15 Acknowledgments..................................................16 Authors Addresses................................................17 Maes Expires - March 2006 [Page 2]
<Lemonade Profile> September 2005 Intellectual Property Statement..................................17 1. Introduction Lemonade provides enhancements to Internet email to support diverse service environments. This document describes the lemonade profile phase 1 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. - 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 IMAP 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 Maes Expires - March 2006 [Page 3]
<Lemonade Profile> September 2005 The act of sending an email message can be thought of as involving multiple steps: initiation of a new draft, draft editing, message assembly, and message submission. Initiation of a new draft and draft editing takes place 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 - March 2006 [Page 4]
<Lemonade Profile> September 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 Maes Expires - March 2006 [Page 5]
<Lemonade Profile> September 2005 the messages on the IMAP server by transmitting new text and assembling them. [UIDPLUS] IMAP extension is used by the client in order to learn the UID of the created messages. Finally a [URLAUTH] format URL is given to a [RFC2476] server for submission using the [BURL] extension. The flow involved to support such a use case consists of: M: {to I -- Optional} The client connects to the IMAP server, 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. 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) M: 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: Maes Expires - March 2006 [Page 6]
<Lemonade Profile> September 2005 M: Our travel agent has sent the updated schedule. M: M: Cheers, M: Bob M: --------------030308070208000400050907 M: URL " /INBOX;UIDVALIDITY=385759045/; UID=25627;Section=2.MIME" URL "/INBOX; UIDVALIDITY=385759045/;UID=25627;Section=2" TEXT {44} I: + Ready for literal data M: M: --------------030308070208000400050907-- M: ) I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) I: A0053 OK STORE completed Note: the UID STORE command shown above will only work if the marked message is in the currently selected mailbox. This command can be omitted. 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= Maes Expires - March 2006 [Page 7]
<Lemonade Profile> September 2005 S: 235 2.7.0 PLAIN authentication successful. M: MAIL FROM:<bob.ar@example.org> S: 250 2.5.0 Address Ok. M: RCPT TO:<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], UIDPLUS [UIDPLUS] and URLAUTH [URLAUTH]. This support MUST be declared via CAPABILITY [RFC3501]. Lemonade compliant submit servers MUST support the BURL [BURL], 8BITMIME [8BITMIME], BINARYMIME [CHUNKING] and CHUNKING [CHUNKING]. This support MUST be declared via EHLO [RFC2821]. Maes Expires - March 2006 [Page 8]
<Lemonade Profile> September 2005 Additional normative statements are provided in other sections. 2.6. Security Considerations for pawn-tickets. The so-called "pawn-ticket" authorization mechanism uses a URI, which contains its own authorization credentials using [URLAUTH]. The advantage of this mechanism is that the SMTP submit [RFC2476] server cannot access any data on the [RFC3501] server without a "pawn- ticket" created by the client. The "pawn-ticket" grants access only to the specific data that the SMTP submit [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 << 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. Maes Expires - March 2006 [Page 9]
<Lemonade Profile> September 2005 Lemonade clients SHOULD take advantage of these features. 3.1. Pipelining Mobile clients regularly use networks with a relatively high latency. Avoidance of round-trips within a transaction has a great advantage for the reduction in both bandwidth and total transaction time. For this reason LEMONADE compliant mail submission servers MUST support the SMTP Service Extensions for Command Pipelining [REF2197]. Clients SHOULD pipeline. 3.2. DSN Support LEMONADE compliant mail submission servers MUST support SMTP service extensions for delivery status notifications [RFC3461]. 3.3. Message size declaration LEMONADE compliant mail submission servers MUST support the SMTP Service Extension for Message Size Declaration [RFC2927]. 3.4. 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. This may also be a voluntary disconnect; something that does not need to be distinguished at the level of the protocol. 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 Maes Expires - March 2006 [Page 10]
<Lemonade Profile> September 2005 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. 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. 5. Additional IMAP extensions Lemonade compliant IMAP servers MUST support the NAMESPACE [NAMESPACE] extension. 6. Summary of IMAP and SMTP extensions required for phase 1 ------------------------------------------------------ |Name of an SMTP extension| Comment | |-------------------------|--------------------------| | PIPELINING | Section 3.1 | Maes Expires - March 2006 [Page 11]
<Lemonade Profile> September 2005 |-------------------------|--------------------------| | DNS | Section 3.2 | |-------------------------|--------------------------| | SIZE | Section 3.3 | |-------------------------|--------------------------| | ENHANCEDSTATUSCODES | Section 3.4 | |-------------------------|--------------------------| | STARTTLS | Section 8.1 | |-------------------------|--------------------------| | BURL | Forward without download,| | | Section 2 | |-------------------------|--------------------------| | 8BITMIME, | Required by BURL | | BINARYMIME, | | | CHUNKING | | |-------------------------|--------------------------| ------------------------------------------------------ |Name of an IMAP extension| Comment | |-------------------------|--------------------------| | NAMESPACE | Section 5 | |-------------------------|--------------------------| | RECONNECT | Section 4 | |-------------------------|--------------------------| | CONDSTORE | Required by RECONNECT | |-------------------------|--------------------------| | STARTTLS |Required by IMAP (RFC3501)| |-------------------------|--------------------------| | URLAUTH, | Forward without download,| | CATENATE, | Section 2 | | UIDPLUS | | |-------------------------|--------------------------| 7. Future work Future phases of the Lemonade profile are expected to address issues related to access of email from mobile devices, possibly including: - Media conversion (static and possibly streamed) - Transport optimization for low or costly bandwidth and less reliable mobile networks - Server to client notifications possibly outside of the traditional IMAP band - Dealing with firewall and intermediaries - Compression and other bandwidth optimization - Filtering - Other considerations for mobile clients Maes Expires - March 2006 [Page 12]
<Lemonade Profile> September 2005 8. Security Considerations Security considerations on Lemonade "forward without download" are discussed throughout section 2. Additional security considerations can be found in [RFC3501], [UIDPLUS], [URLAUTH], [BURL] and [RECONNECT]. 8.1. TLS When LEMONADE clients uses the BURL extension to mail Submission, an extension that requires sending a URLAUTH token to the mail submission server, such a token should be protected from interception to avoid a replay attack that will disclose the contents of the message to an 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]. Clients are expected to authenticate with the submit server. LEMONADE Compliant IMAP servers MUST support IMAP over TLS [RFC3501] as required by RFC 3501. Clients are expected to authenticate with the IMAP server. 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 connection when fetching message content using the URLAUTH token provided by the LEMONADE client. When a client uses SMTP STARTTLS to send a BURL command which references non-public information there is a user expectation that the entire message content will be treated confidentially. To address this expectation, the message submission server should use STARTTLS or a mechanism providing equivalent data confidentiality when fetching the content referenced by that URL. 9. IANA Considerations This document doesn't require any IANA registration or action. 10. References 10.1. Normative References Maes Expires - March 2006 [Page 13]
<Lemonade Profile> September 2005 [BURL] Newman, C. "Message Composition", draft-ietf-lemonade-burl- XX.txt (work in progress). [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000. [CATENATE] Resnick, P. "Internet Message Access Protocol (IMAP) CATENATE Extension", draft-ietf-lemonade-catenate-XX, (work in progress). [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", work in progress, draft-crispin-imap- rfc2359bis-XX.txt. [POSTADDRESS] Melnikov, A. "IMAP4 POSTADDRESS extension", work in progress, draft-melnikov-imap-postaddress-XX.txt [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 [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 [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 Maes Expires - March 2006 [Page 14]
<Lemonade Profile> September 2005 [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. [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998. [SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. 10.2. Informative References [IMAP-DISC] Melnikov, A. "Synchronization Operations For Disconnected Imap4 Clients", IMAP-DISC, work in progress, draft- melnikov-imap-disc-XX.txt Open issues This section will be deleted before publication. [1] Cleanup/finish Security Considerations, in particular the section talking about TLS. Add a new section talking about authentication? [2] Add a table summarizing different IMAP/SMTP extensions? [3] Decide if POSTADDRESS is part of the Lemonade profile phase 1. [4] Ensures that Quick reconnect syntax follows the quick reconnect draft. Version History This section will be deleted before publication. Version 04: [1] Removed future delivery from the phase 1 of the profile. [2] Updated the list of required SMTP and IMAP extensions and associated normative statements. [3] Updated the references. [4] Moved (and updated) text about TLS to the Security Considerations section. [5] Removed most editorÆs notes. [6] Proposed terminology Lemonade profile phase 1 (and later phases) to distinguish current status from future work. Version 03: Maes Expires - March 2006 [Page 15]
<Lemonade Profile> September 2005 [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 a product of Lemonade WG. The editorsÆ thanks the Lemonade WG members that contributed comments and corrections, in particular: Randy Gellens. This document borrows some text from draft-crispin-lemonade-pull- xx.txt as well as the trio [BURL], [CATENATE] and [URLAUTH]. Maes Expires - March 2006 [Page 16]
<Lemonade Profile> September 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 - March 2006 [Page 17]
<Lemonade Profile> September 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 - March 2006 [Page 18]
