WDIFF

draft-ietf-lemonade-profile-01.txt --> draft-ietf-lemonade-profile-02.txt

Lemonade
Internet Draft: Lemonade Profile S. H. Maes
Document: draft-ietf-lemonade-profile-01.txt draft-ietf-lemonade-profile-02.txt A. Melnikov
Expires: August October 2005 February April 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 aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes the Lemonade a profile to allow (a set of required extensions,
restrictions and usage modes) of mail protocols such as IMAP and
Submission. This profile allows clients (especially those that are
constrained in memory, bandwidth, processing power, or other areas)
to
submit new email messages incorporating content which resides on
locations external efficiently use IMAP and Submission to access and submit mail.
This includes the client ("forward ability to forward received mail without download"). 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 other various protocols;
specifically URLAUTH, CATENATE, Lemonade Command Extensions in the
IMAP protocol [RFC 3501] [RFC3501] and BURL in the SUBMIT protocol [RFC 2476]. [RFC2476].

Maes Expires - October 2005 [Page 1]

<Lemonade Profile> April 2005

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

Conventions used in this document

Maes Expires - August 2005 [Page 1]

<Lemonade Profile> February 2005

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.................................1 document........................... 2
Table of Contents.................................................2 Contents........................................... 2
1. Introduction...................................................2 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..................................4 description............................ 5
2.5. Additional Considerations.................................8 Normative statements related to forward without
download ........................................... 8
2.6. Additional Considerations........................... 8
2.7. The fcc problem...........................................8 problem..................................... 9
3. Media Conversion...............................................9 Message Submission....................................... 9
3.1. Introduction..............................................9 Future Delivery..................................... 9
3.2. Static media conversion...................................9 Pipelining..........................................10
3.3. Conversion of streamed media..............................9 TLS.................................................10
3.4. DSN Support ........................................11
3.5. Message size declaration............................11
4. Quick Reconnect scheme....................................9
4. scheme...................................11
4.1. Normative statements related to quick reconnect
schemes ........................................... 12
5. Future work...................................................10 work............................................. 12
Security Considerations..........................................10
References.......................................................10 Considerations.................................... 13
IANA Considerations ....................................... 13
References................................................. 13
Version History..................................................12
Acknowledgments..................................................12 History............................................ 14
Acknowledgments............................................ 15
Authors Addresses................................................12 Addresses.......................................... 15
Intellectual Property Statement..................................12 Statement............................ 15
Full Copyright Statement.........................................13 Statement................................... 16

Maes Expires - October 2005 [Page 2]

<Lemonade Profile> April 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 that describes exchanges between
Lemonade Agents to allow clients to submit new email messages
incorporating content which resides on locations external to
the client and allow forward without download.
- Media conversion

Maes Expires - August 2005 [Page 2]

<Lemonade Profile> February 2005
- Quick reconnect

The organization of this document is as follows. Section 2 describes
the Lemonade Pull Model. Section 3 Section 3 describes the Media
Conversion. Section 4 describes quick reconnect

2. Forward without download

2.1. Motivations

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

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

Pull has the distinct advantage of maintaining one submission protocol, and
thus avoids the risk of having multiple parallel and possible
divergent mechanisms for submission. Furthermore, by keeping the
details of message submission in the SMTP SUBMIT server, the Lemonade
Pull Model can work with other message retrieval protocols such as
POP, NNTP, or whatever else may be designed in the future.

2.2. Message Sending Overview

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

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

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.

Maes Expires - August 2005 [Page 3]

<Lemonade Profile> February 2005

2.3. Traditional Strategy

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

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

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

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

2.4.
Step by step description

Maes Expires - August October 2005 [Page 4]

<Lemonade Profile> February April 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 Lemonade Pull Model allows a Messaging User Agent to compose and
forward an e-mail combining fragments that are located in an IMAP
server, without having to download these fragments to the server.

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

The flow involved to support such a use case consists of:
M: {to I -- Optional} The client connectects to the IMAP server
and IMAP Fetch of body structures and UIDs (See [RFC3501])

Example:
M: A0051 FETCH 161 (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" "PLAIN" ("CHARSET" "US-ASCII"
"NAME"
"cc.diff")
"<960723163407.20117h@washington.example.net>" "Compiler
diff"

Maes Expires - August 2005 [Page 5]

<Lemonade Profile> February 2005
"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 already
present on the IMAP server.

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

M: A0052 CATENATE Sent FLAGS (\Seen $MDNSent) 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
M: --------------030308070208000400050907
M: URL "imap://imap.example.org/INBOX;UIDVALIDITY=385759045/;
UID=25627;Section=1.2" TEXT {44}
I: + Ready for literal data
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 +FLAGS.SILENT ($Forwarded)
I: A0053 OK STORE completed

<< Editor�s note: Recommend UIDPLUS extension � especially useful
when appending messages to a non-selected mailbox>>

Maes Expires - August 2005 [Page 6]

<Lemonade Profile> February 2005

M: {to I} The client uses GENURLAUTH command to request and
URLAUTH URL (See [URLAUTH]).
I: {to M} The IMAP server returns 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" INTERNAL
I: * GENURLAUTH
"imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;uid=45/;urla
uth=submit+bar:internal:91354a473744909de610943775f92038"
I: A0054 OK GENURLAUTH completed

M: {to S} The client connects to the SMTP 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.
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 LAST

S: {to I} The SMTP 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).

Submission

SMTP submission server opens IMAP connection to the IMAP server:

I: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP
server ready

Maes Expires - August 2005 [Page 7]

<Lemonade Profile> February 2005
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"
I: * URLFETCH "
imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;uid=45/;urlau
th=submit+bar:internal:91354a473744909de610943775f92038" {15065}
...message body follows...
S: a002 OK URLFETCH completed

<< Editor�s note: The SMTP submission server may LOGOUT>>

S2: {to M} OK (2XX)

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

The messaging user agent,

2.5. Normative statements related to forward without download

Lemonade compliant mail server MUST therefore respectively support
IMAPv4 Rev1 [RFC3501], CATENATE [CATENATE] and URLAUTH [URLAUTH]. Its
support MUST be declared via CAPABILITY [RFC3501].

Lemonade compliant SMTP submit server servers MUST support BURL extensions
[BURL]. Its support MUST be declared via EHLO [RFC2821].

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

2.5.

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

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 a copy of the
message to a "file carbon copy" recipient. By far, the most common
case of fcc is a client leaving a copy of outgoing mail in a "sent
messages" or "outbox" mailbox.

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

The [CATENATE] extension to [RFC3501] addresses the fcc problem. It
requires making several simplifying assumptions:

Maes Expires - August 2005 [Page 8]

<Lemonade Profile> February 2005
(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.
Media Conversion Message Submission

LEMONADE compliant SMTP submission server are expected to implement a
set of SMTP extensions to make message submission efficient. The
clients SHOULD take advantage of these features.

3.1.
Introduction

<<Editor�s note: To 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 done when agreed by WG>>

3.2.
Static media conversion

<<Editor�s note: To of interest to email users to be done when agreed
able to take advantage of future delivery by WG>>

3.3.
Conversion marking ahead of streamed media time a
message for future submission into the mail system.

For well-connected devices, the client can hold a message in the
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 submission servers MUST 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
submission server may advertise a future delivery interval of zero
seconds.

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

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

When dealing with an device that support future delivery, such
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 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 Submission, a
protocol that requires sending a URLAUTH token to the SMTP 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 SMTP submission path will
provide protection against this attack.

LEMONADE Compliant SMTP 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 clients SHOULD use TLS protected SMTP submission channels
when agreed by WG>> using BURL-based message submission to protect the URLAUTH token
from interception.

3.4. DSN Support

It is expected that a LEMONADE compliant SMTP submission servers
supports delivery status notifications.

LEMONADE compliant SMTP 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>>

3.5. Message size declaration

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

4. Quick Reconnect scheme

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

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

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

Maes Expires - August October 2005 [Page 9] 11]

<Lemonade Profile> February April 2005

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

5. Future work

Future versions of the Lemonade profile are expected to address
issues related to access of email form 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 compression

Maes Expires - October 2005 [Page 12]

<Lemonade Profile> April 2005

- filtering

Security Considerations

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

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

IANA Considerations

Lemonade profile extensions should be appropriately related to the
list of IMAP and SMTP parameters.

References

Maes Expires - August 2005 [Page 10]

<Lemonade Profile> February 2005

[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

[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

[RFC2476]

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

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

[BURL] Newman, C., "Message Composition", draft-ietf-lemonade-
burl-xx (work in progress).
(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).

[POSTADDRESS] Melnikov, A., "IMAP4 POSTADDRESS extension",

Version History

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 in
progress, draft-melnikov-imap-postaddress-XX.txt
[6] Add section 4.1 on normative statements related to quick
reconnect scheme.

Maes Expires - August October 2005 [Page 11] 14]

<Lemonade Profile> February April 2005

[RECONNECT] Melnikov, A.

[6] Addition of Binary and C. Wilson, " IMAP4 extension for quick
reconnect ", 8-bit MIME Transport to future work in progress, draft-ietf-lemonade-reconnect-
XX.txt
[7] Addition of IANA statement
[8] Update and fix of the references

Version History 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 �Copriright�. �Copyright�.

Acknowledgments

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

Authors Addresses

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

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

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in

Maes Expires - August October 2005 [Page 12] 15]

<Lemonade Profile> February April 2005

this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

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

Acknowledgement

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

Full Copyright Statement

Copyright (C) The Internet Society 2004. 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.

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.

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

Maes Expires - August October 2005 [Page 13] 16]

<Lemonade Profile> February 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 by the Internet Society or its successors or assigns.

Maes Expires - August October 2005 [Page 14] 17]

----