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

Versions: 00 01

          <Lemonade in TCP Challenged Environments>            June 2006

Lemonade                                                     S. H. Maes
Internet Draft: Lemonade TCP Challenged                     R. Cromwell
Environments                                                  (Editors)

Document: draft-maes-lemonade-tcp-challenged-
Expires: December 2006                                        June 2006

                  Lemonade in TCP Challenged Environments

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 30, 2006.


   The IETF lemonade group has defined extensions to the IMAP and SMTP
   protocols that provide optimizations for clients in a variety of
   settings, such as mobile networks. This document discusses issues
   related to deployments where TCP support in the client is degraded or
   non-existent, and techniques for overcoming these limitations.

Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

Maes                   Expires – December 2006               [Page 1]

          <Lemonade in TCP Challenged Environments>            June 2006

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST or REQUIRED level requirements for the protocol(s) it
   implements. An implementation that satisfies all the MUST or REQUIRED
   level and all the SHOULD level requirements for a protocol is said to
   be "unconditionally compliant" to that protocol; one that satisfies
   all the MUST level requirements but not all the SHOULD level
   requirements is said to be "conditionally compliant."  When
   describing the general syntax, some definitions are omitted as they
   are defined in [RFC3501], [RFC821], and related documents.

Table of Contents

   Status of this Memo...............................................1
   Conventions used in this document.................................1
   Table of Contents.................................................2
   1. Introduction and motivation....................................2
   2. Techniques.....................................................3
      2.1. Tunneling Approaches......................................3
         2.1.1. Non-Persistent HTTP for Batch Connectivity Mode......5
         2.1.2. Using Persistent HTTP/HTTPS + Chunked Transfer
                Encoding for Stream Connectivity Mode................7
         2.1.3. Using HTTP as a binding for SMTP.....................8
   3. Asynchronous Approaches........................................8
      3.1. Transmission Methods......................................9
      3.2. Authentication............................................9
      3.3. Response Payload..........................................9
   4. Tracking and Controlling Tunneled Traffic......................9
   5. Security Considerations.......................................10
   Future Work......................................................11
   Version History..................................................11
   Authors Addresses................................................12
   Intellectual Property Statement..................................12
   Disclaimer of Validity...........................................13
   Copyright Statement..............................................13

   Introduction and motivation

   The IETF lemonade working group is designing a set of extensions to
   IMAP and SMTP to facilitate access to internet email in diverse
   service environments, such as on resource constrained devices, and

Maes                   Expires – December 2006               [Page 2]

          <Lemonade in TCP Challenged Environments>            June 2006

   slow or high latency networks. The preferred model and best current
   practices for doing this is described in [DEPLOYMENTS].

   Not all networks and clients permit the preferred deployment model at
   this point in time, such as some devices which do not provide a TCP
   stack to the application (some mobile phones and set-top box
   environments), and some networks with very high and unpredictable
   latency like satellite networks. Over time, it is expected that as
   technology improves, some of these limitations will be lifted to
   permit deployment using best current practices. However, it is
   desirable to provide some form of access for users of these networks
   until that time.


   Examples of major markets that have some TCP limitations include:

   - Some Java MIDP devices do not permit arbitrary TCP, but do permit
   - TV Set-top box providers which may provide degraded TCP or HTTP
   over MPEG-2
   - Global satellite wireless networks which provide email in remote
   environments and at sea.

   This document considers two techniques to overcome these
   difficulties. The first is HTTP Tunneling to attempt regular IMAP and
   SMTP layered on top of HTTP. The second technique is a URL mapping
   approach which uses [IMAPURL] as a compact representation for sending
   batches of IMAP commands over severely limited physical networks like
   two-way satellite networks.

   Servers and clients adhering to this draft MUST support HTTP
   tunneling, and MAY support section 3's IMAPURL approach.

        Tunneling Approaches

   There are two approaches for achieving tunneling over HTTP, depending
   on whether keep-alive chunked-transfer-encoded is supported by any
   intermediaries in the network (i.e. HTTP proxy servers) or not. The
   general approach is to use a content-type for packaging a payload of
   IMAP commands, described below.

   To use HTTP/HTTPS as the transfer protocol for IMAP commands and
   responses between the IMAP client and server, the client MUST send an
   HTTP POST request to the server, and embed IMAP commands (commands to
   an IMAPv4 Rev1 server or IMAP servers supporting Lemonade extensions)
   in the body of the request. A server MUST reject a HTTP GET request
   from the client.  The content-type header of the POST request MUST be
   set to "application/vnd.lemonade.imap".  Multiple IMAP commands may

Maes                   Expires – December 2006               [Page 3]

          <Lemonade in TCP Challenged Environments>            June 2006

   be included in one POST request. In general, the HTTP server is
   expected to preserve session state between HTTP commands to the best
   of its ability, therefore the client does not need to reauthenticate
   and reissue a SELECT until it receives an (IMAP) error response
   showing that it is not authenticated.

   In what follows, the term Lemonade client/server is used to refer to
   a client/server that supports both IMAPv4 Rev1 as well as any
   LEMONADE extensions.

   When the HTTP binding is used, the Lemonade server listens on
   whatever port has been configured for this.

   The following is an example of a Lemonade HTTP request:

      POST /lemonadePath HTTP/1.1 <CRLF>
      Content-Type: application/vnd.lemonade.imap <CRLF>
      X-Http-Binding: imap <CRLF>
      [other headers]
      (<tag> SP <Lemonade command> <CRLF> | literal )
      [(<tag> SP <Lemonade command> <CRLF> | literal )]

   The Lemonade command MUST be plain text (7bit).

   Multiple Lemonade commands MAY be sent on the same request. The
   client must be able to deal with recovering from errors when commands
   are batched. See RFC2442 Batch SMTP for a further discussion. In
   general, if a command is expected to produce a synchronized literal
   or continuation request, it MUST be the last command in the batch.

   The Content-Type and X-Http-Binding headers are the only HTTP headers
   that MUST be sent to a Lemonade server. Other headers such as Cache-
   Control MAY be included.

   When the Lemonade server sends back a response it is in following

      HTTP/1.1 <HTTP Status Code> <CRLF>
      Content-Type: application/vnd.lemonade.imap <CRLF>
      X-Http-Binding: imap <CRLF>
      [<untagged responses>]
      <tag> SP <Lemonade Server response> <CRLF>
      [<untagged responses>]
      <tag> SP <Lemonade Server response> <CRLF>

   The Lemonade Server uses the following HTTP status codes, and what
   each code indicates is given below:

Maes                   Expires – December 2006               [Page 4]

          <Lemonade in TCP Challenged Environments>            June 2006

   - 200
        -This indicates normal execution of the Lemonade commands from
        an IMAP perspective.    The client should further parse the
        response body to get the tagged responses to the commands and
        process those accordingly.

   - 401
         - This indicates that the execution of the IMAP commands might
         have been successful, but the session is no longer
         authenticated. The client should try to reauthenticate to the
         IMAP server, and then resend the commands.

   - 5xx
         - This indicates that at least one command was
         malformed/protocol level error, or, a command could not
         complete due to a problem in the IMAP server. In conforming to
         HTTP semantics, this means the IMAP server responses such as
         BAD or NO on a tagged response generate a HTTP 500 response
         code.  Also, if the HTTP request includes batched commands
         after the command which generates a continuation request or
         synchronized literal, the server MUST generate a 5xx request.

   When using HTTP to transfer IMAP commands and responses, the client
   SHOULD utilize built-in features of HTTP to their advantage.  For
   example, the client SHOULD use HTTPS instead of HTTP whenever
   possible, since HTTPS has built in encryption and MAY have
   compression capabilities.

   HTTP can be used in both batch and stream modes.  Details about these
   transport modes are given in the following two subsections.

          Non-Persistent HTTP for Batch Connectivity Mode

   If the client uses a traditional HTTP connection (either by
   establishing a different socket for each HTTP request to the Lemonade
   server, or by reusing the same socket for all HTTP requests, but
   sending each request in different HTTP commands), it has batch
   connectivity to the server.  The client can issue as many commands as
   it would like in one HTTP request to the server, and the server
   responds by sending back one HTTP response with all the responses to
   all the commands in the HTTP request.  With this connectivity mode,
   the IDLE command nor any commands that depend on unsolicited
   responses in a session. Other commands that use a continuation
   response or synchronized literal cannot be issued unless they are the
   last command in the batch. [LITERAL+] SHOULD be used to eliminate
   synchronized literals when using APPEND.

Maes                   Expires – December 2006               [Page 5]

          <Lemonade in TCP Challenged Environments>            June 2006

   In order for the server to identify separate HTTP requests as
   belonging to the same session, a batch HTTP client needs to accept
   cookies.  A session-id is passed in the cookie to identify the

   Example: the headers for a HTTP batch response after the client has
   issued its first HTTP request to the server.

      HTTP/1.1 <HTTP Status Code> <CRLF>
      Content-Type: application/vnd.lemonade.imap <CRLF>
      X-Http-Binding: imap <CRLF>
      [<untagged responses>]
      <tag> SP <Lemnade Server response> <CRLF>
      [[<untagged responses>]
      <tag> SP <Lemonade Server response> <CRLF>]

   Example: the headers for a HTTP batch response after the client has
   issued its first HTTP request to the server, with the final command
   generating a continuation request.

      HTTP/1.1 200 Ok <CRLF>
      Content-Type: application/vnd.lemonade.imap <CRLF>
      X-Http-Binding: imap <CRLF>
      [<untagged responses>]
      <tag> SP <Lemnade Server response> <CRLF>

   The client must then save this cookie and send it back to the server
   with the next request in order for the server to reattach these
   commands to the same session as the previous commands.

      POST /lemonadePath HTTP/1.1 <CRLF>
      Content-Type: application/vnd.lemonade.imap <CRLF>
      X-Http-Binding: imap <CRLF>
      Cookie: JSESSIONID=94571a8530d91e1913bfydafa
      [other headers]
      <tag> SP <Lemonade command> <CRLF>
      [<tag> SP <Lemonade command> <CRLF>]

Maes                   Expires – December 2006               [Page 6]

          <Lemonade in TCP Challenged Environments>            June 2006

          Using Persistent HTTP/HTTPS + Chunked Transfer Encoding for
       Stream Connectivity Mode

   It is possible to use persistent HTTP or persistent HTTPS plus
   chunked-transfer-encoding so that the client and server can use
   stream style communications. The client needs to open a persistent
   HTTP connection and keep it active. In this case, the HTTP headers
   must be sent the first time the client device opens the connection to
   the Lemonade Server and these headers MUST set the transfer coding to
   be chunk-encoded [RFC2616, Sec. 3.6.1]. All subsequent client-server
   requests are written to the open connection, without needing any
   additional HTTP headers. In this case, the client does not need to
   accept cookies.

   The client must send the HTTP headers one time only:

      POST /lemonadeServletPath HTTP/1.1 <CRLF>
      Content-Type: application/vnd.lemonade.imap <CRLF>
      Connection: keep-alive <CRLF>
      X-Http-Binding: imap <CRLF>
      Pragma: no-cache <CRLF>
      Transfer-Encoding: chunked <CRLF>

   The server responds with the following header:

      HTTP/1.1 <HTTP Status Code> <CRLF>
      Cache-Control: private
      Keep-Alive: timeout=15, max=100 (or other suitable setting)
      Connection: Keep-Alive
      X-Http-Binding: imap <CRLF>
      Transfer-Encoding: chunked
      Content-Type: application/vnd.lemonade.imap

   Then the client can send a command anytime it wants with the
   following format:
      <length of Lemonade command, including bytes in CRLF> <CRLF>
      <tag> SP <Lemonade command> <CRLF>

   And example of an actual client command is:
      e <CRLF>

   The server responds to each command with as many untagged responses
   as needed, and one tagged response, where each response is in the
   format that follows:

Maes                   Expires – December 2006               [Page 7]

          <Lemonade in TCP Challenged Environments>            June 2006

      <length of a single response, including bytes in CRLF> <CRLF>
      <tagged or untagged response> <CRLF>

   An actual Server response might be:
      d5 <CRLF>
   <CRLF>   <CRLF>
      1b <CRLF>
      2 OK CAPABILITY completed <CRLF>

   Note however that the HTTP protocol is in general not meant to be
   used in such a way. To maintain such an open channel might be a
   practical challenge to proxies, which might not forward the requests
   chunk by chunk to the server, and meanwhile route responses back to
   the client chunk by chunk. Consequently the session closes. Chunked
   transfer encoding requests MAY not be honored by an HTTP proxy
   server. In cases where such requests are denied, the client should be
   prepared to use the non-chunked encoding technique from section

   The session may be automatically started again by the client after a
   lost connection or by the server through out-of-band; after some
   defined time-out.

          Using HTTP as a binding for SMTP

      All of the techniques described in sections 2.1 may be used for
   SMTP as well. The only difference between IMAP and SMTP will be the
   HTTP URL used. Servers implementing the HTTP binding are expected to
   differentiate between IMAP and SMTP protocol bodies via the URL.

  Asynchronous Approaches

   Some networks, such as satellite networks, may present challenges to
   the HTTP request-response approach in the preceding chapter due to
   extreme latency. Clients expecting near-synchronous response to IMAP
   commands would face huge delays, and may inappropriately timeout too
   soon, or provide a UI to the user that is geared around immediate
   response which will expose long delays to end users.

   Satellite networks resemble store-and-forward systems, it is thus
   desirable to provide a mechanism for interacting with an IMAP

Maes                   Expires – December 2006               [Page 8]

          <Lemonade in TCP Challenged Environments>            June 2006

   Lemonade server that is geared for asynchronous requests and

   [IMAPURL] already provides a standard for encoding a series of IMAP
   commands into a compact URL, and describes a subset of functionality
   that is adequately suited to accessing email when roaming on
   satellite networks.

        Transmission Methods

   It is not in the scope of this document to describe the mechanism by
   which IMAPURL payloads are sent through such networks (which are
   typically proprietary) However, the end result should be an HTTP
   request invoked on a server which decodes the IMAPURL payload and
   processes the request on behalf of the client.

   IMAPURLs of the form imap://<iserver>/path?query where iserver =
   [iuserinfo "@"] host [":" port] must be rewritten into a URL of the
   following form:


   where <enc-imapurl> is imap://<iserver>/path?query encoded according
   to standard HTTP url encoding.


   <<Ray: TBD, Perhaps the Delay Tolerant Networking working group has
   some material on authenticating over DTNs? Or perhaps a mechanism for
   obtaining longer lived URLAUTH tokens which can be reused multiple
   URLs within a time span?>>

        Response Payload

   The response to any IMAPURL processed according to [IMAPURL] on the
   server should be sent to the client as a set of raw IMAP responses.
   However, [IMAPURL] suggests that the result of a search should be to
   fetch all the messages returned from the SEARCH.  For the purposes of
   this document, the result of an IMAPURL containing a search should be
   the SEARCH response from the IMAP server, without performing any

  Tracking and Controlling Tunneled Traffic

   In order to simplify deployment and provisioning issues, as well as
   help network administrators track and control IMAP/SMTP traffic
   wrapped in HTTP requests, the HTTP requests and responses of a

Maes                   Expires – December 2006               [Page 9]

          <Lemonade in TCP Challenged Environments>            June 2006

   binding should provide a non-ambiguous way of recognizing binding

   It is therefore mandated that a "X-HTTP-Binding" HTTP header MUST
   specified in all requests and responses. The header may take a value
   of "imap" or "smtp" depending on the type of traffic being tunneled.

  Security Considerations

   The HTTPS protocol can and should be used to provide end-to-end
   security where it is available when tunneling, especially because of
   the existence of HTTP proxies.

   Caching is also a concern, especially if HTTPS isn't used. The client
   SHOULD use the HTTP Cache-Control directive (no-cache, no-store,
   must-revalidate, or combinations thereof) to inform proxy servers,
   origin servers, and client libraries not to cache or store the HTTP
   response. To deal with HTTP 1.0 servers that may exist in the
   network, Pragma: no-cache should be used as well.

   Attacks on HTTP sessions and the HTTP server may also be a concern,
   since the HTTP server is maintaining an authenticated session to the
   IMAP server on behalf of the user in most cases.

   Network administrators wishing to block stealth deployments of HTTP
   IMAP bindings may block HTTP requests with Content-Type
   application/vnd.lemonade.[imap|smtp]  via an application level
   firewall and/or block any HTTP traffic with the X-Http-Binding header


   [DEPLOYMENTS] Gellens, R., " Deployment Considerations for lemonade-
   compliant Mobile Email", draft-ietf-lemonade-deployments-03.txt, June

   [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile",
   draft-ietf-lemonade-profile-XX.txt, (work in progress).

   [LUOTONEN] Luotonen, A., “Tunneling TCP based protocols through Web
   proxy servers”, draft-luotonen-web-proxy-tunneling-01.txt, August

   [LITERAL+] Myers, J. “IMAP non-synchronizing literals”, RFC2088,
   January 1997

Maes                   Expires – December 2006              [Page 10]

          <Lemonade in TCP Challenged Environments>            June 2006

   [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
   Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S-
   M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Protocol
   (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress).

   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.

   [RFC2442] Freed, N. et al. "The Batch SMTP Media Type", RFC 2442,
   November 1998.

   [RFC2616] Fielding, R. et al.  "Hypertext Transfer Protocol --
   HTTP/1.1", RFC 2616, June 1999.

   [RFC2817] Khare, R., “Upgrading to TLS Within HTTP/1.1”, RFC2817, May
      http://www.ietf.org/rfc/rfc2817.txt, May 2000

   [RFC3205] Moore, K. ”On the use of HTTP as a Substrate”, RFC 3205,
   February 2002.

   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
   Version 4 rev1", RFC 3501, March 2003.

Future Work

   - Detail normative statements on binding method to support versus
   other options that were considered.

Version History

   Release 01
      Change name and focus to TCP challenged environment
      Emphasize usage in challenged network and platform environments
      Added more examples of challenged environments
      Discussion of IMAPURL for satellite networks,
      New X-HTTP-Binding header
      Normative statements

   Release 00
      Rename from firewall binding.

Maes                   Expires – December 2006              [Page 11]

          <Lemonade in TCP Challenged Environments>            June 2006


   The authors want to thank all who have contributed key insight and
   extensively reviewed and discussed the concepts in this draft as well
   as the authors of the early introduction of the binding concept in

Authors Addresses

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

   Ray Cromwell
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065

   Nilo Mitra
   Tel: +1 212-843-8451
   Email: nilo.mitra@ericsson.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

Maes                   Expires – December 2006              [Page 12]

          <Lemonade in TCP Challenged Environments>            June 2006

   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-

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

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


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

Maes                   Expires – December 2006              [Page 13]

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