Lemonade
Internet Draft: Lemonade Profile S. H. Maes
Document: draft-ietf-lemonade-profile-00.txt A. Melnikov
Expires: January 2005 July 2004
Lemonade Profile
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the Lemonade profile to allow clients to
submit new email messages incorporating content which resides on
locations external to the client ("forward without download") and to
optimize e-mail exchanges between clients and servers in a mobile
environment.
The Lemonade profile relies upon extensions to other protocols;
specifically URLAUTH, CATENATE, Lemonade Command Extensions in the
IMAP protocol [RFC 3501] and BURL in the SUBMIT protocol [RFC 2476].
It also provides optimization in a mobile setting, aimed at
delivering extended functionality for mobile devices with limited
resources by relying on Lemonade Server to Client Notifications to
support to push crucial changes actively to a client, rather then
requiring the client to initiate contact to ask for state changes.
Maes Expires - January 2005 [Page 1]
<Lemonade Profile> July 2004
In addition, the Lemonade profile contains Lemonade Command
extensions for email filter management, message delivery, maintaining
up-to-date personal information and quick reconnect.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
Status of this Memo...............................................1
Abstract..........................................................1
Conventions used in this document.................................2
Table of Contents.................................................2
1. Introduction...................................................3
2. The Lemonade Pull Model........................................3
2.1. Motivations...............................................3
2.2. Message Sending Overview..................................3
2.3. Traditional Strategy......................................4
2.4. Forward without download..................................4
2.5. Additional Considerations.................................6
2.6. The fcc problem...........................................6
3. Mobile Optimization............................................7
3.1. Introduction..............................................7
3.2. Motivation................................................7
3.3. The Poll Model vs. the Push Model.........................7
3.4. Synchronization Techniques................................8
3.4.1. State-Comparison-Based Synchronization...............9
3.4.2. Event-based Synchronization.........................10
3.5. The Server-Side Filtering in Lemonade Profile............11
3.6. Lemonade Command Extensions..............................11
3.7. Fast Reconnect...........................................12
3.8. HTTP Binding.............................................12
3.9. Revisions to IMAPv4 Rev1 Behavior........................12
Security Considerations..........................................13
References.......................................................13
Acknowledgments..................................................15
Authors Addresses................................................15
Intellectual Property Statement..................................15
Full Copyright Statement.........................................16
Maes Expires - January 2005 [Page 2]
<Lemonade Profile> July 2004
1. Introduction
Lemonade provides enhancements to Internet email to support diverse
service environments.
This document describes the lemonade profile that includes:
- The Lemonade Pull Model that describes exchanges between
Lemonade Agents to allow clients to submit new email messages
incorporating content which resides on locations external to
the client.
- Mobile optimizations that defines extensions to the IMAPv4 Rev1
protocol [RFC3501] aimed at delivering extended functionality
for mobile devices with limited resources including support to
push crucial changes actively to a client, rather then
requiring the client to initiate contact to ask for state
changes and extensions for email filter management, message
delivery, and maintaining up-to-date personal information and
quick reconnect.
The organization of this document is as follows. Section 2 describes
the Lemonade Pull Model. Section 3 describes the Lemonade Mobile
Optimizations.
2. The Lemonade Pull Model
2.1. Motivations
The advent of client/server email using the [RFC3501] and [RFC2821]
protocols has changed what formerly were local disk operations to
become excessive and repetitive network data transmissions. This is
an onerous burden for clients operating over low-bandwidth and/or
high-latency links.
The Lemonade Pull Model makes use of the [BURL] SUBMIT extension to
enable access to external sources during the submission of a message.
In combination with the IMAP [URLAUTH] extension, inclusion of
message parts or even entire messages from the IMAP mail store is
possible with a minimal trust relationship between the IMAP and
SUBMIT servers.
Pull has the distinct advantage of maintaining one submission
protocol, and thus avoids the risk of having multiple parallel and
possible divergent mechanisms for submission. Furthermore, by
keeping the details of message submission in the SUBMIT server, the
Lemonade Pull Model can work with other message retrieval protocols
such as POP, NNTP, or whatever else may be designed in the future.
2.2. Message Sending Overview
Maes Expires - January 2005 [Page 3]
<Lemonade Profile> July 2004
The act of sending an email message is best thought of as involving
multiple steps: initiation of a new draft, draft editing, message
assembly, and message submission.
Initiation of a new draft and draft editing takes place on the MUA.
Frequently, users choose to save more complex and/or time-consuming
messages on an [RFC3501] server (via the APPEND command with the
\Draft flag) for later recall by the MUA and resumption of the
editing process.
Message assembly is the process of producing a complete message from
the final revision of the draft and external sources. At assembly
time, external data is retrieved and inserted in the message.
Message submission is the process of inserting the assembled message
into the [RFC2821] infrastructure, typically using the [RFC2476]
protocol.
2.3. Traditional Strategy
Traditionally, messages are initiated, edited, and assembled entirely
within an MUA, although drafts may be saved to an [RFC3501] server
and later retrieved from the server. The completed text is then
transmitted to an MSA for delivery.
There is often no clear boundary between the editing and assembly
process. If a message is forwarded, its content is often retrieved
immediately and inserted into the message text. Similarly, once
external content is inserted or attached, the content is usually
retrieved immediately and made part of the draft.
As a consequence, each save of a draft and subsequent retrieve of the
draft transmits that entire (possibly large) content, as does message
submission.
In the past, this was not much of a problem, because drafts, external
data, and the message submission mechanism were typically located on
the same system as the MUA. The most common problem was running out
of disk quota.
2.4. Forward without download
The model distinguishes between a Messaging User Agent (MUA), an
IMAPv4Rev1 Server ([RFC3501]) and a submit server ([RFC2476]), as
illustrated in Figure 1.
+--------------------+ +--------------+
| | <------------ | |
| MUA | | IMAPv4 Rev1 |
Maes Expires - January 2005 [Page 4]
<Lemonade Profile> July 2004
| | | Server |
| | ------------> | (Server S1) |
+--------------------+ +--------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | v
| | +--------------+
| |------------------------->| |
| | Submit |
|-----------------------------| Server |
| (Server S2) |
+--------------+
Figure 1: Lemonade Pull Model
The Lemonade Pull Model allows a Messaging User Agent to compose and
forward an e-mail combining fragments that are located in an IMAP
server, without having to download these fragments to the server.
In the [BURL]/[CATENATE] variant of the pull strategy, messages are
initiated and edited within an MUA. The [CATENATE] extension to
[RFC3501] is then used to upload the message to the IMAP server and
assemble it, and finally a [URLAUTH] format URL is given to a
[RFC2476] server with the [BURL] extension for submission.
The flow involved to support such a use case consists of:
M: {to S1 -- Optional} The client uses IMAP Fetch of body
structures (See [RFC3501])
M: {to S1} The client invokes CATENATE (See [CATENATE] for details
of the semantics and steps û this allows the MUA to create messages
on the IMAP using new data combined with body structure already
present on the IMAP server.
S1: {to M} OK (See [CATENATE]).
M: {to S1} The client uses GENURLAUTH command to request and
URLAUTH URL (See [URLAUTH]).
S1: {to M} The IMAP server returns URLAUTH URL suitable for later
retrieval with URLFETCH (See [URLAUTH] for details of the semantics
and steps).
M: {to S2} The client connects to the submission server and starts
a new mail transaction. It uses BURL to let the submit server fetch
the content of the message from the IMAP server (See [BURL] for
details of the semantics and steps û this allows the MUA to
authorize the submit server to access the message composed as a
result of the CATENATE step).
Maes Expires - January 2005 [Page 5]
<Lemonade Profile> July 2004
S2: {to S1} The submission server uses URLFETCH to fetch the
message to be sent (See [URLAUTH] for details of the semantics and
steps. The so-called "pawn-ticket" authorization mechanism uses a
URI which contains its own authorization credentials.).
S1: {to S2} Provides the message composed as a result of the
CATENATE step).
S2: {to M} OK (2XX)
The messaging user agent, mail server and submit server MUST support
IMAPv4 Rev1 [RFC3501], CATENATE [CATENATE] and URLAUTH [URLAUTH].
2.5. Additional Considerations
The so-called "pawn-ticket" authorization mechanism uses a URI which
contains its own authorization credentials using [URLAUTH]. The
advantage of this mechanism is that the submit [RFC2476] server can
not access any data on the [RFC3501] server without a "pawn-ticket"
created by the client. The "pawn-ticket" grants acces only to the
specific data that the submit [RFC2476] server is authorized to
access, can be revoked by the client, and can have a time-limited
validity.
2.6. The fcc problem
The "fcc problem" refers to a frequent need to deliver a copy of the
message to a "file carbon copy" recipient. By far, the most common
case of fcc is a client leaving a copy of outgoing mail in a "sent
messages" or "outbox" mailbox.
In the traditional strategy, the MUA duplicates the effort spent in
transmitting to the MSA by writing the message to the fcc destination
in a separate step. This may be a write to a local disk file or an
APPEND to a mailbox on an IMAP server. The latter is one of the
"excessive and repetitive network data transmissions" which
represents the "problem" aspect of the "fcc problem".
The [CATENATE] extension to [RFC3501] addresses the fcc problem. It
requires making several simplifying assumptions:
(1a) there is one, and only one, fcc destination on a single
server
(2a) the server which holds the fcc is the same as the server
which stages the outgoing message for submission
(3a) it is desired that the fcc be a copy of the complete message
text with all external data inserted in the message
<<[POSTADDRESS] can be used to address issues (1a) and (2a). To be
done later>>
Maes Expires - January 2005 [Page 6]
<Lemonade Profile> July 2004
3. Mobile Optimization
3.1. Introduction
The Lemonade profile provides optimizations for the exchanges between
a mobile client and e-mail server by specifying additional
enhancements for optimization in a mobile setting. Thus, the client
devices in this profile are assumed to be mobile with limited
resources. This profile takes into account the limited resources of
mobile devices, as well as extra functionality desired.
Figure 2 illustrates the exchanges specified by the mobile
optimizations of the Lemonade Profile.
The e-mail server MAY comply with the Lemonade Pull Model described
in section 2.
+--------------------+ +--------------+
| Mobile | <------------ | |
| Lemonade | | Lemonade |
| E-mail Client | |E-mail Server |
| | ------------> | |
+--------------------+ +--------------+
Figure 2: Lemonade CS Profile Model
A disconnected mobile client should behave like a good disconnected
client [IMAP-DISC].
Additional requirements for optimization for Mobile access are
discussed in section 3.6.
3.2. Motivation
Today, most of the existing email clients have a polling model, where
the end user is notified of changes to an email account only after
his/her email client asks the server, called polling. How long it
takes a client to learn of a change on the server is thus dependent
on how often the client polls for changes. Many clients can poll at
high rates so that the client can quickly learn of changes and
reflect them on the client display to achieve a quasi-real time.
The mobile optimization of the Lemonade profile can support both Poll
and Push Models.
3.3. The Poll Model vs. the Push Model
Today, most of the existing email clients implement a polling model,
where the end user is notified of changes to an email account only
after the email client polls the server for changes. How long it
Maes Expires - January 2005 [Page 7]
<Lemonade Profile> July 2004
takes a client to learn of a change on the server is thus dependent
on how often the client polls for changes. Many clients can poll at
high rates so that the client can quickly learn of changes and
reflect them on the client display to achieve a quasi-real time
synchronization experience for the end user. The periodic poll model
is used on conventional email clients. Because the client must
continuously poll the server for changes, the bandwidth requirements
can be quite high and the connection quality must be good in order to
provide a quasi-real time experience to the user. This also
generates additional load on the IMAP server. The periodic poll
model is illustrated in Figure 2.
+--------------------+ Poll +--------------+
| | <------------ | |
| Mail Server | | Email Client |
| | ------------> | |
+--------------------+ Response +--------------+
Figure 3: Periodic Poll Model
Another way to achieve synchronization is for the email server to
initiate a session with the client when a crucial change to an email
occurs, which is the push model. When important events happen to a
userÆs email account, the server informs the client device about the
event, and then the client can respond to that event as necessary.
In this case, the client device does not need to periodically poll
the mail server, so the push model is particularly effective in the
mobile computing environment when the cost of constant polling is
high. [NOTIFICATIONS] defines the semantics for pushing events to a
client. The push model is seen in Figure 2.
Event +----------------+ Push +--------------+
--------> | Mail Server | ---------> | Email Client |
+----------------+ +--------------+
Figure 4: Push Model
3.4. Synchronization Techniques
After a client receives a notification that informs it that changes
have occurred to a mailbox, it needs to employ a synchronization
technique to reflect the server side changes onto the client device.
There are many techniques for determining what the changes between a
server and client are. In this section, two techniques are presented
that aim to keep a client device in sync with a given email account,
meaning that the set of messages on the client device is the same as
that in the given email account.
Maes Expires - January 2005 [Page 8]
<Lemonade Profile> July 2004
3.4.1. State-Comparison-Based Synchronization
IMAPv4Rev1 clients use a state-comparison-based synchronization
technique to be in sync with an email account. This technique
requires the client to ask the server for information regarding all
the folders and all the messages in each folder stored on the server.
The client must then compute the difference between the server state
and the client device state, and make all necessary changes so that
the client device state matches the server state. An example of the
interaction between the client and server in the IMAPv4Rev1 protocol
for performing a state-comparison-based sync follows. This is
described in more details in [IMAP-DISC].
First, the client must retrieve the folders from the server. The
client should issue LIST to figure out which folders has to be
retrieved. It than uses LSUB to determine which folders are
subscribed. For example:
C: A002 LIST "" "%"
S: * LIST (\NoInferiors) "/" "Drafts"
S: * LIST () "/" "Friends"
S: * LIST (\NoInferiors) "/" "INBOX"
S: A002 OK completed
C: A003 LSUB "" "*"
S: * LSUB () "/" "Drafts"
S: * LSUB () "/" "Friends"
S: * LSUB () "/" "INBOX"
S: A003 OK LSUB completed
Note, that the client should not use LIST "" *, as it might cause too
much data to be returned. This is discussed in [RFC2683] in more
details.
The client must compare its folders with the responses of the command
above. If it does not have a folder, it must create that folder on
the client device. If there is a folder on the device that is not in
any of these responses, then the client must delete that folder. In
order to avoid loosing changes performed on the client, the client
should apply its changes first. In case when the client has changes
to a folder that was deleted on the server, it should ask the user
whether the changes should be uploaded to a different mailbox or be
discarded (or be configured to automatically do one of the two).
Next, the client needs to make sure that the emails in each of its
folders match the server. It performs a SELECT and then a FETCH
command for each folder. A sample of a SELECT and FETCH command for
the inbox is as follows:
C: A003 SELECT ôINBOX"
S: * 60 EXISTS
Maes Expires - January 2005 [Page 9]
<Lemonade Profile> July 2004
S: ... more untagged responses with information about the folder
S: A003 OK SELECT completed
C: A004 FETCH 1:* (FLAGS UID)
S: * 1 FETCH (FLAGS (\Answered) UID 120)
S: * 2 FETCH (FLAGS (\Seen) UID 121)
S: ... flags for messages with message sequence numbers 3-59
S: * 60 FETCH (FLAGS () UID 250)
S: A004 OK FETCH completed
The client must go through the full list of email messages in each
folder. It must download an email message from this list if it is
not already on the client. Any changes to the mutable flags a
message must be reflected on the server using IMAP STORE command.
Also, the client should remove any emails on the client device not in
this list. After performing these operations, the client is in sync
with the server.
<<Need to check if this matches [IMAP-DISC]>>
3.4.2. Event-based Synchronization
Another technique is event-based synchronization. Event-based
synchronization is used to keep the client device in sync with the
server. This method requires that the client has been fully
synchronized with the server at some earlier point. In the
IMAPv4Rev1 protocol, the client must perform a state-comparison-based
sync when it selects a folder, but then it can use event-based
synchronization to keep itself in sync after that. Although event-
based synchronization cannot totally replace state-comparison-based
synchronization, it is a faster alternative for the client to
maintain synchrony when the server is capable of change tracking for
a client.
In event-based synchronization, the server keeps track of what
changes have occurred to the email account that are not yet reflected
on the client device. Such a change is called an event. When the
client finishes processing all events since the last time it was in
sync with the server, it is again in sync with the server. Event-
based synchronization is particularly effective when the server can
push events to the client for immediate processing. In this case,
there are likely to be only a small number of events the client needs
to process at one time.
Also, when a Lemonade client drops a connection or accidentally
disconnects the server can retain the session and cache all events
during the time the client is disconnected. When the client
reconnects it does not need to perform a state-comparison-based
synchronization all over again, and the server sends the list of
pending events to the client..
Maes Expires - January 2005 [Page 10]
<Lemonade Profile> July 2004
Lemonade Mobile Clients and Servers MUST support Lemonade Server to
Client Notifications as described in [NOTIFICATIONS].
3.5. The Server-Side Filtering in Lemonade Profile
The Lemonade server MUST support Server-side filtering as described
in [NOTIFICATIONS].
3.6. Lemonade Command Extensions
The Lemonade server MUST support the rich set of extra functionality
over the IMAP server to support extra features for a mobile client
described as Lemonade Command Extensions in [EXTENSIONS]. These
include:
[1] Compression û Lemonade CS Profile allows for compression of
responses to a command. Preliminary testing results shows
significant performance results when the response to FETCH FLAGS or
header information are compressed. Details are found in
[EXTENSIONS].
[2] Sending emails - The Lemonade server can be used to send email,
thus eliminating the need for the Lemonade client to connect to a
separate SMTP server. When interfacing with a server that supports
LEMONADEDELIVER as discovered via CAPABILITY commands as described
in [Extensions], this is the mechanism that SHOULD be used.
Otherwise, the client is expected to implement the Lemonade Pull
Model described in section 2.
[3] Support for unstable mobile connections û After a client drops
a connection, the Lemonade server can temporarily maintain the
session for the mobile client. During this time, the server caches
any events concerning the mobile repository while the client is
disconnected, which it can then send to the client upon
reconnection. This is described in more details in Section 3.7 of
this document.
[4] Longer periods of inactivity tolerated - A Lemonade server
should wait at least 24 hours before logging out an inactive mobile
client and ending its session. <<This may lead to Deny of Service.
To be investigated.>>
[5] Attachments forward/reply behavior - When forwarding/replying
to a message from the Lemonade client, the end user may choose to
reattach the original's message attachments by just specifying the
UID of the original message and specifiers for the required
bodyparts. The client need not download the attachments of the
Maes Expires - January 2005 [Page 11]
<Lemonade Profile> July 2004
original message itself. This is an expected server behavior. It
MAY also be implemented following the Lemonade Pull Model.
[6] Attachments conversion - The Lemonade server can convert
attachments to other formats to be viewed on a mobile device. This
is an expected server behavior.
[7] PIM - The protocol also provides support for updating personal
information on a client device, even when these changes are
initiated from another client (i.e. a personal assistant connects
to an end userÆs account from a desktop and changes contact
information.) These additional uses are especially useful for
mobile devices, where end users need up-to-date information on the
fly. <<This requires additional work to store calendaring and
address book informations.>>
3.7. Fast Reconnect
Mobile operators usually charge users for the time their mobile
client gets connected to the Internet and/or for the amount of
information sent/received. Thus a mobile client should minimize time
it stays connected to its mail server, which suggests that it should
disconnect and reconnect frequently.
Also, it is possible that the mobile client unexpectedly leaves area
of connectivity, which will require that the client reconnects when
connectivity returns.
IMAP can be verbose. Usually, in order to synchronize a client with a
server after a disconnect, the client needs to issue at least the
following commands: LOGIN/AUTHENTICATE, SELECT and several FETCH
commands (see [IMAP-DISC] for more details).
Thus, there is a desire to have a quick reconnect facility in IMAP,
which will give a mobile client ability to resume a previously
abandoned session, without the need to perform the full
synchronization sequence as described above.
<<Note, we need an example here with and without the extension. To Be
Done.>>
3.8. HTTP Binding
For mobile clients, the Lemonade Profile exchanges MAY be transported
on HTTP as described in [HTTPBINDINGS].
3.9. Revisions to IMAPv4 Rev1 Behavior
Maes Expires - January 2005 [Page 12]
<Lemonade Profile> July 2004
A Lemonade server MUST responds to all IMAPv4Rev1 commands. A
compliant Lemonade server must implement all the commands in IMAPv4
Rev1, with the revisions described in [NOTIFICATIONS] and
[EXTENSIONS].
Security Considerations
Security considerations on the Lemonade Pull Model are discussed
throughout section 2.
The mobile optimization of the Lemonade profile calls for the same
security requirements for an in-response and inband connectivity mode
as IMAP.
For the outband connectivity mode, servers should use encryption
methods for notifications if sensitive information is included in the
payload of that notification.
When an implementation of Lemonade Mobile Profile is proxy-based,
this may create new security issues. These issues are discussed in
detail in [EXTENSIONS], because the issues are dependent on the
implementation of this protocol rather than inherent to the protocol
itself.
References
[OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August
2002. http://www.openmobilealliance.org/tech/docs/EmailNot/OMA-
Push-EMN-V1_0-20020830-C.pdf
[IMAP-DISC] Melnikov, A. "Synchronization Operations For
Disconnected Imap4 Clients", IMAP-DISC, work in progress, draft-
melnikov-imap-disc-XX.txt
[RFC2119] Brader, S. "Keywords for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119
[RFC2180] Gahrns, M. "IMAP4 Multi-Accessed Mailbox Practice", RFC
2180, July 1997.
http://www.ietf.org/rfc/rfc2180
[RFC2234] Crocker, D. and Overell, P. "Augmented BNF for Syntax
Specifications", RFC 2234, Nov 1997.
http://www.ietf.org/rfc/rfc2234
Maes Expires - January 2005 [Page 13]
<Lemonade Profile> July 2004
[RFC2420] Kummert, H. "The PPP Triple-DES Encryption Protocol
(3DESE)", RFC 2420, September 1998.
http://www.ietf.org/rfc/rfc2420
[RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
http://www.ietf.org/rfc/rfc2616
[RFC2617] Franks, J. et al. "HTTP Authentication: Basic and Digest
Access Authentication", RFC 2617, June 1999.
http://www.ietf.org/rfc/rfc2617
[RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683
Sep 1999.
http://www.ietf.org/rfc/rfc2683
[RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997.
http://www.ietf.org/rfc/rfc2177
[RFC2818] Rescorla, E. "HTTP over TLS", RFC 2818, May 2000.
http://www.ietf.org/rfc/rfc2818
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April
2001. http://www.ietf.org/rfc/rfc2822
[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
Version 4 rev1", RFC 3501, March 2003.
http://www.ietf.org/rfc/rfc3501
[RFC2476] Gellens, R. and Klensin, J., "Message Submission", RFC
2476, December 1998.
[CATENATE]Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", draft-ietf-lemonade-catenate-01, (work in
progress), January 2004.
[BURL] Newman, C., "Message Composition", draft-newman-lemonade-
compose-00.txt (work in progress), June 2003.
[URLAUTH] Crispin, M. and Newman, C., "Internet Message Access
Protocol (IMAP) - URLAUTH Extension", draft-crispin-imap-urlauth-
09.txt, (work in progress), July 2004.
[EXTENSIONS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
Chiu, E., "Lemonade Command Extensions", draft-maes-lemonade-
command-extensions-00.txt, (work in progress), July 2004.
Maes Expires - January 2005 [Page 14]
<Lemonade Profile> July 2004
[NOTIFICATIONS] Maes, S.H. and Wilson C., "Lemonade Server to Client
Notifications", draft-ietf-lemonade-server-to-client-
notifications-00.txt, (work in progress), July 2004.
[HTTPBINDINGS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V.
and Chiu, E., "Lemonade HTTP Binding", draft-maes-lemonade-http-
binding-00.txt, (work in progress), July 2004.
[POSTADDRESS] Melnikov, A., "IMAP4 POSTADDRESS extension", work in
progress, draft-melnikov-imap-postaddress-XX.txt
Acknowledgments
This document is based on the work in progress described in draft-
crispin-lemonade-pull-01.txt and draft-maes-lemonade-p-imap-03.txt.
Authors Addresses
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
M/S 4op634
Redwood Shores, CA 94065
USA
Phone: +1-650-607-6296
Email: stephane.maes@oracle.com
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex
TW12 2BX
UK
Email: Alexey.melnikov@isode.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
Maes Expires - January 2005 [Page 15]
<Lemonade Profile> July 2004
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Full Copyright Statement
Copyright (C) The Internet Society 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Maes Expires - January 2005 [Page 16]
