<IMAP HTTP Binding>            January 2005


Lemonade                                                     S. H. Maes
Internet Draft: IMAP HTTP Binding                           R. Cromwell
                                                               N. Mitra
                                                              (Editors)

Document: draft-maes-lemonade-http-binding-04
Expires: July 2006                                         January 2006


                        IMAP and SMTP HTTP Binding

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.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   As part of the LEMONADE work to define extensions to the IMAPv4 Rev1
   protocol [RFC3501] and SMTP that provide optimizations in a variety
   of settings,  the this document  describes an alternative, optional
   binding for IMAPv4 and SMTP showing how HTTP can be used to transfer
   commands and responses. This binding is intended to facilitate the
   use of IMAP and SMTP in deployments involving a variety of
   intermediaries. A binding to SOAP is also provided.




Maes                     Expires – July 2006                 [Page 1]


                         <IMAP HTTP Binding>            January 2005


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

   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
   Copyright Notice..................................................1
   Abstract..........................................................1
   Conventions used in this document.................................2
   Table of Contents.................................................2
   1. Introduction and motivation....................................2
   2. Techniques for binding over HTTP...............................4
      2.1. Tunneling Approaches......................................4
         2.1.1. Non-Persistent HTTP for In-response Connectivity
                Mode.................................................6
         2.1.2. Using Persistent HTTP/HTTPS + Chunked Transfer
                Encoding for In-band Connectivity Mode...............7
         2.1.3. Using HTTP Connect...................................8
         2.1.4. Using HTTP as a binding for SMTP.....................9
      2.2. Using SOAP (Web Services) as a binding for IMAP...........9
   3. Security Considerations.......................................11
   4. References....................................................11
   5. Future Work...................................................13
   6. Version History...............................................13
   Acknowledgments..................................................14
   Authors Addresses................................................14
   Intellectual Property Statement..................................16
   Disclaimer of Validity...........................................16
   Copyright Statement..............................................16


1.
   Introduction and motivation



Maes                     Expires – July 2006                 [Page 2]


                         <IMAP HTTP Binding>            January 2005


   As part of the LEMONADE goal to define extensions to the IMAPv4 Rev1
   protocol [RFC3501] for providing optimizations in a variety of
   settings, this document describes how HTTP can optionally be used to
   transfer IMAP and SMTP commands and responses. This binding is
   intended to facilitate the use of IMAP and SMTP in deployments
   involving a variety of intermediaries, and offers a standardized
   alternative to de facto proprietary implementations of such a
   feature.

   The need for an optional HTTP binding is driven by the needs of the
   mobile network operator community (see [MEMAIL][OMA-ME-RD]), where
   the reuse of an existing and well-understood technology will allow
   operators to apply their experience in solving practical deployment
   issues. Specifically, HTTP allow operators to reuse a similar setup
   and model that is already used for many other similar and related
   services, such as certain proprietary push e-mail and synchronization
   offerings, OMA Data Synchronization, Web services and Web access.

   Using HTTP/HTTPS can simplify deployment in a corporate network
   through the potential use of a reverse proxy to achieve end-to-end
   encryption. This also has the advantage of not requiring changes to
   any firewall configurations and reduces the concerns that this often
   presents to corporation. In general the solution is compatible with
   any existing firewall. A reverse proxy can also support deployment
   models that offer roles to other service providers in the value
   chains, as discussed in [OMA-ME-AD].

   The confidentiality, integrity, and compression capabilities used
   with HTTP and already implemented in a wide range of existing mobile
   device, which be also be reused.

   Studies have also shown that a persistent HTTP session has usually
   proven more resilient than an IMAP IDLE over TCP connection over an
   unreliable bearer such as a GPRS-based mobile network.

   The use of HTTP as an underlying protocol for other application
   protocols has received much attention (see [RFC3205]). In particular,
   the concern exists that this circumvents firewall security policies.
   Another concern is the potential misuse or neglect of HTTP semantics
   by the application protocol that uses HTTP as a substrate.

   Note that if the suppression of IMAP (or indeed any other
   application) traffic on HTTP/HTTPS is an issue, firewall
   administrators can still prevent such passage and this can provide
   incentives to re-configure firewalls to allow solutions on other
   transports (e.g. TLS) or offer the HTTP-based solution using another
   provisioned port (e.g. manually, out of band or via instructions like
   XGETLPREFS (see [NOTIFICATIONS])). The aim, therefore, is to allow
   for the use of this solution in the widest possible set of


Maes                     Expires – July 2006                 [Page 3]


                         <IMAP HTTP Binding>            January 2005


   circumstances by codifying a standard way to do so that works with
   existing, deployed (i.e., HTTP only) firewalls, while explicitly
   allowing the possibility of detecting and filtering such traffic in
   deployments using the HTTP Content-Type in deployments where this is
   not permitted.

   A SOAP binding is also described.



2.
  Techniques for binding over HTTP

   There are two approaches described below for binding IMAP over HTTP.
   The first approach shows how to tunnel regular IMAP requests and
   responses over HTTP using POST. The second method proposes a
   syntactic change which recodes IMAP requests and responses as SOAP
   documents, and IMAP commands as SOAP methods.

   <Editor’s note: More approaches and a rationalization of the possible
   approach will be added later.>

2.1.
    Tunneling Approaches

   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".  Multiple IMAP commands may 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 possible Lemonade HTTP request:

      POST /lemonadePath HTTP/1.1 <CRLF>
      Content-Type: application/vnd.lemonade <CRLF>
      [other headers]
      <CRLF>


Maes                     Expires – July 2006                 [Page 4]


                         <IMAP HTTP Binding>            January 2005


      <tag> SP <Lemonade command> <CRLF>
      [<tag> SP <Lemonade command> <CRLF>]

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

   Multiple Lemonade commands MAY be sent on the same request. Thus
   Lemonade commands must be tagged. The client must be able to deal
   with recovering from errors when commands are batched. See RFC2442
   Batch SMTP for a further discussion.

   The Content-Type header is 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 MUST be in the
   following format:
      HTTP/1.1 <HTTP Status Code> <CRLF>
      Content-Type: text/plain <CRLF>
      <CRLF>
      [<untagged responses>]
      <tag> SP <Lemonade Server response> <CRLF>
      [[<untagged responses>]
      <tag> SP <Lemonade Server response> <CRLF>]

   Notes:
   The Lemonade Server uses the following HTTP status codes, and what
   each code indicates is given below:
      - 200
        - This indicates normal execution of the Lemonade commands
           from a IMAP perspective.    The client should further parse
           the response body to get the tagged responses to the
           commands and process those accordingly.

      - 500
         - This indicates that at least one command caused an internal
         server error, meaning the Lemonade Server failed to execute the
         command. In conforming to HTTP semantics, this means the IMAP
         server responses such as BAD or NO IMAP generate a HTTP 500
         response code.

   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.  STARTTLS should not be needed in this
   case, as it just requires additional overhead without any additional
   benefit.




Maes                     Expires – July 2006                 [Page 5]


                         <IMAP HTTP Binding>            January 2005


   HTTP can be used in both in-response and in-band modes.  Details
   about these transport modes are given in the following two
   subsections.


2.1.1. Non-Persistent HTTP for In-response 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 under its own header), it has in-response
   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 cannot be issued. Other commands that use a
   continuation response cannot be issued unless the
   LITERAL+ [RFC2088] extension is supported.

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

   Thus, the headers for a HTTP In-response Response after the client
   has issued its first HTTP request to the server.

      HTTP/1.1 <HTTP Status Code> <CRLF>
      Content-Type: text/plain <CRLF>
      Set-Cookie:JSESSIONID=94571a8530d91e1913bfydafa;
   path=/lemonade<CRLF>
      <CRLF>
      [<untagged responses>]
      <tag> SP <Lemnade Server response> <CRLF>
      [[<untagged responses>]
      <tag> SP <Lemonade 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 <CRLF>
      Cookie: JSESSIONID=94571a8530d91e1913bfydafa
      [other headers]
      <CRLF>
      <tag> SP <Lemonade command> <CRLF>
      [<tag> SP <Lemonade command> <CRLF>]


Maes                     Expires – July 2006                 [Page 6]


                         <IMAP HTTP Binding>            January 2005




2.1.2. Using Persistent HTTP/HTTPS + Chunked Transfer Encoding for In-
band Connectivity Mode

   It is possible to use persistent HTTP or persistent HTTPS plus
   chunked- transfer-encoding so that the server can instantly send
   notifications to the client while a session is open.  The client
   needs to open a persistent 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 headers negotiations. The
   server can use this open channel to push events to the client device
   at any time. In this case, the client SHOULD NOT accept cookies.

   The client must send the HTTP headers one time only:

      POST /lemonadeServletPath HTTP/1.1 <CRLF>
      Content-Type: application/vnd.lemonade <CRLF>
      Connection: keep-alive <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
      Transfer-Encoding: chunked
      Content-Type: text/plain


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

   And example of an actual client command is:
      e <CRLF>
      2 CAPABILITY<CRLF>
      <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 – July 2006                 [Page 7]


                         <IMAP HTTP Binding>            January 2005


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

   An actual Server response might be:
      d5 <CRLF>
      * CAPABILITY IMAP4REV1 AUTH=LOGIN NAMESPACE SORT MULTIAPPEND
   LITERAL+ UIDPLUS IDLE XORACLE X-ORACLE-LIST X-ORACLE-COMMENT X-
   ORACLE-QUOTA X-ORACLE-PREF X-ORACLE-MOVE X-ORACLE-DELETE ACL X-
   ORACLE-PASSWORD LDELIVER LZIP LCONVERT LFILTER LSETPREF LGETPREF
   <CRLF>   <CRLF>
      1b <CRLF>
      2 OK CAPABILITY completed <CRLF>
      <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/firewalls, 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
   server. In cases where such requests are denied, the client should be
   prepared to use the non-chunked encoding technique from section 2.1


   The same challenges exist for TCP session.

   In any case, the session can be automatically started again by the
   client after a lost connection or by the server through out-of-band;
   after some defined time-out.


2.1.3. Using HTTP Connect

   If a HTTP proxy server is available to the client which supports the
   HTTP CONNECT method, and the IMAP server the user wishes to reach
   allows external connections outside the destination network’s
   firewall, the client may wish to tunnel a regular TCP connection
   through the HTTP proxy.

      See [LUOTONEN] or section 5.2 of [RFC2817] for a detailed
   description of the technique. Note that HTTP Proxy servers may not
   honor all CONNECT requests, and may in fact, limit CONNECT requests
   to a small number of common ports, such as 80, 443, 8080, etc. It is
   advised that networks wishing to allow their users to use this
   feature allow clients within their network to CONNECT to ports 25,
   143, 587, and 993.



Maes                     Expires – July 2006                 [Page 8]


                         <IMAP HTTP Binding>            January 2005



2.1.4. Using HTTP as a binding for SMTP

      All of the techniques described in sections 2.1, 2.2, and 2.3 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.

2.2.
    Using SOAP (Web Services) as a binding for IMAP

   The SOAP binding attempts to map IMAP commands to SOAP methods, and
   IMAP data types and grammar (atoms, lists, et al) to document-
   literals supplied as the soap body. This is essentially a tunneling
   technique with a syntactic change. The following general encoding
   rules are proposed:

   IMAP commands are translated into SOAP methods of the same name, e.g.
   the “FETCH” command becomes the “FETCH” SOAP method name. (UID FETCH
   is mapped to UID_FETCH).
   SOAP document literal style is used
   Terminals in the IMAP grammar which represent atoms become elements.
   (e.g. FLAGS becomes <FLAGS/>) Flags are stripped of leading backslash
   and uppercased.
   Non-terminals which of an ATOM followed by a single parameter are
   represented as a non-empty element containing that parameter. (e.g.
   CHARSET foo becomes <CHARSET>foo</CHARSET>, or SENTBEFORE date
   becomes <SENTBEFORE>date</SENTBEFORE>
   Lists are represented as <L> </L> containing zero or more elements
   (including other <L>s)
   Unless otherwise defined, if a particular keyword is followed by more
   than one value, each value is encoded as <P>value</P> as placed as a
   child element. E.g. APPEND mailbox SP flaglist SP literal becomes
   <APPEND><P>mailbox</P><P><L><ANSWERED/><DRAFT/></L></P></APPEND>
   Continuation responses and requests are encapsulated as <C>data</C>
   Literals are encapsulated as <T>text</T> or <B>binary</B>
   Unsolicited responses are encapsulates as <U>response</U>
    The partial specifier is <P>offset.length</P>
    The section specifier is <SECTION>…</SECTION>
    A sequence set is wrapped as <SEQUENCE>sequence-set</SEQUENCE>
    The IMAP response is encoded in <RESP>response</RESP>
   Any responses which start with a number followed by an ATOM are
   encoded as <ATOM>number</ATOM>

   The following is an example encoding:

   C: a1 FETCH 1:5,9 BODY[1.1.CONVERT(“TEXT/PLAIN”)]<1024.2048>

   Becomes


Maes                     Expires – July 2006                 [Page 9]


                         <IMAP HTTP Binding>            January 2005



   <FETCH>
      <SEQUENCE>1:5,9</SEQUENCE>
     <BODY>
         <SECTION>
            <P>1.1.CONVERT(“TEXT/PLAIN”)</P>
          </SECTION>
         <P>1024.2048</P>
      </BODY>
   </FETCH>

   Which would then be invoked on a Web Service via the SOAPMethodName
   “FETCH”. The expected response would be zero or more <U> elements
   containing <FETCH> elements which encode the returned data.

   These rules are by no means complete and exhaustive, and more
   stringent encoding rules are needed to encompass the full range of
   IMAP extended ABNF. The above rules are provided as a starting point.

   SOAP by itself adds considerable overhead to requests, so it would
   not be recommended without some form of compression or compact
   encoding such as “Fast Web Services” (X.695 “ASN.1 Support for SOAP,
   Web Services and the XML Information Set”)[X.695]. However, SOAP may
   provide some benefits over raw HTTP for those who have existing
   investments in SOAP infrastructure.

   As a final note, the above usage once again, assumes that the soap
   server is not stateless and uses HTTP cookies to preserve IMAP
   session state between requests.

   Here’s an example session side by side with IMAP syntax(SOAP envelop
   not shown):

   C-SOAP: <LOGIN><P>username</P><P>password</P>
   C-IMAP: a1 LOGIN username password

   S-SOAP: <RESP><OK>LOGIN Ok</OK>
   S-IMAP: * OK LOGIN Ok

   C-SOAP: <SELECT>INBOX</SELECT>
   C-IMAP: a2 SELECT INBOX

   S-SOAP: <RESP>
      <U><FLAGS><L><ANSWERED/><DRAFT/><FLAGGED/><SEEN/></L></FLAGS></U>
      <U><OK><PERMANENTFLAGS><L><ANSWERED/><DRAFT/><FLAGGED/><SEEN/></L>
   </PERMANENTFLAGS></OK></U>
      <U><EXISTS>1234</EXISTS></U>
      <U><RECENT>0</RECENT></U>
      <U><OK><UIDVALIDITY>12345678</UIDVALIDITY></OK></U>


Maes                     Expires – July 2006                [Page 10]


                         <IMAP HTTP Binding>            January 2005


      <OK><READ-WRITE/></OK>
      </RESP>

   S-IMAP: * FLAGS (\Answered \Draft \Flagged \Seen)
   S-IMAP: * OK [PERMANENTFLAGS (\Answered \Draft \Flagged \Seen)]
   S-IMAP: * 1234 EXISTS
   S-IMAP: * 0 RECENT
   S-IMAP: * Ok [UIDVALIDITY 12345678]
   S-IMAP: a2 OK [READ-WRITE]


3.
  Security Considerations

   HTTP binding has the same security requirements as IMAP when using an
   in-response or inband connectivity mode.

   The HTTPS protocol can be used to provide end-to-end security

   Proxy-based implementations may still require payload encryption for
   end-to-end security.

   Caching is a concern. 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.

   Firewall administrators wishing to block stealth deployments of HTTP
   IMAP bindings may block HTTP requests with Content-Type
   application/vnd.lemonade via an application level firewall.


4.
  References

   [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
   1998

   [MEMAIL] Maes, S.H., “Lemonade and Mobile e-mail", draft-maes-
      lemonade-mobile-email-xx.txt, (work in progress).



Maes                     Expires – July 2006                [Page 11]


                         <IMAP HTTP Binding>            January 2005


   [NOTIFICATIONS] 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., "Server to Client
      Notifications and Filtering", draft-ietf-lemonade-server-to-
      client-notifications-xx.txt, (work in progress).

   [OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document,
      (Work in progress).  http://www.openmobilealliance.org/

   [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document,
      (Work in progress).  http://www.openmobilealliance.org/

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

   [RFC2088] Myers, J. “IMAP non-synchronizing literals”, RFC2088,
      January 1997
      http://www.ietf.org/rfc/rfc2088

   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate
      Requirement Levels", RFC 2119, March 1997.
      http://www.ietf.org/rfc/rfc2119

   [RFC2442] Freed, N. et al. "The Batch SMTP Media Type", RFC 2442,
      November 1998.
      http://www.ietf.org/rfc/rfc2442

   [RFC2616] Fielding, R. et al.  "Hypertext Transfer Protocol --
      HTTP/1.1", RFC 2616, June 1999.
      http://www.ietf.org/rfc/rfc2616

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

   [RFC3205] Moore, K. ”On the use of HTTP as a Substrate”, RFC 3205,
      February 2002.
   http://www.ietf.org/rfc/rfc3205

   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
      Version 4 rev1", RFC 3501, March 2003.
      http://www.ietf.org/rfc/rfc3501

   [X.695] X.695 “ASN.1 Support for SOAP, Web Services and the XML
      Information Set”, ITU/ISO



Maes                     Expires – July 2006                [Page 12]


                         <IMAP HTTP Binding>            January 2005


      http://java.sun.com/developer/technicalArticles/WebServices/fastWS
      /


5.
  Future Work

   [1] Should an OPTIONS HTTP request be supported to allow a client to
   probe HTTP binding capabilities, such as which protocol a given URL
   is bound to, or whether chunking is supported?

   [2] Should separate content types exist for IMAP and SMTP since the
   entity body in the HTTP request is different?

   [3] Standardizing the form of the URL for the binding may permit
   firewall administrations to impose better filtering.

   [4] Investigate WebDAV binding and any DAV extensions (if any) needed

   [5] Investigate REST binding

   [6] Present a detailed formalism for the possible methods:

         - HTTP CONNECT
         - HTTP POST (disconnected)
         - HTTP POST + Chunked (persistent)
         - SOAP
         - DAV

6.
  Version History

   Release 04
      Added SMTP and Future Work.
      Clarified caching policy.
      Initial SOAP binding

   Release 03
      Removed material on Notifications and connectivity models
      Updated introduction with motivation
      Editorial corrections

   Release 02
      New section that allows to select the HTTP URL.
      New section 4 to motivate the introduction of an HTTP binding.
      Editorial updates

   Release 01
      Detail updates of the text throughout the document following
      lessons learned so far in P-IMAP 07 [P-IMAP].



Maes                     Expires – July 2006                [Page 13]


                         <IMAP HTTP Binding>            January 2005


   Release 00
      Initial release published in June 2004.

Acknowledgments

   The authors want to thank all who have contributed key insight and
   extensively reviewed and discussed the concepts of HTTP Bindings and
   its early introduction in P-IMAP [P-IMAP].

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

   Rafiul Ahad
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065
   USA

   Eugene Chiu
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065
   USA

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

   Jia-der Day
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065
   USA

   Wook-Hyun Jeong
   Samsung Electronics,CO., LTD
   416, Maetan-3dong, Yeongtong-gu,
   Suwon-city, Gyeonggi-do,
   Korea 442-600


Maes                     Expires – July 2006                [Page 14]


                         <IMAP HTTP Binding>            January 2005


   Tel: +82-31-279-8289
   E-mail: wh75.jeong@samsung.com

   Chang Kuang
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065
   USA

   Rodrigo Lima
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065
   USA

   Nilo Mitra
   Ericsson
   Tel: +1 212-843-8451
   Email: nilo.mitra@ericsson.com

   Gustaf Rosell
   Sony Ericsson
   P.O. Box 64
   SE-164 94 Kista,
   Sweden
   Tel: +46 8 508 780 00

   Jean Sini
   6480 Via Del Oro
   San Jose, CA 95119
   USA

   Sung-Mu Son
   LG Electronics
   Mobile Communication Technology Research Lab.
   Tel: +82-31-450-1910
   E-Mail: sungmus@lge.com

   Fan Xiaohui
   Product Development Division
   R&D CENTER
   CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC)
   ADD: 53A, Xibianmennei Ave.,Xuanwu District,
   Beijing,100053
   China
   TEL:+86 10 66006688 EXT 3137

   Zhao Lijun
   CMCC R&D


Maes                     Expires – July 2006                [Page 15]


                         <IMAP HTTP Binding>            January 2005


   ADD: 53A, Xibianmennei Ave.,Xuanwu District,
   Beijing,100053
   China
   TEL:.8610.66006688.3041

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.

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

Acknowledgement

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


Maes                     Expires – July 2006                [Page 16]


                         <IMAP HTTP Binding>            January 2005





















































Maes                     Expires – July 2006                [Page 17]