<Lemonade HTTP Binding> July 2005 Lemonade Internet Draft: Lemonade HTTP Binding S. H. Maes Document: draft-maes-lemonade-http-binding-01 C. Kuang R. Lima R. Cromwell V. Ha E. Chiu J. Day R. Ahad Oracle Corporation Wook-Hyun Jeong Samsung Electronics Co., LTD Gustaf Rosell Sony Ericsson J. Sini Symbol Technologies Sung-Mu Son LGE Fan Xiaohui Zhao Lijun China Mobile Expires: January 2006 July 2005 Lemonade HTTP Binding 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 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 Maes Expires û January 2006 [Page 1]
<Lemonade HTTP Binding> July 2005 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 As part of the Lemonade work to define extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources, Lemonade HTTP binding describes how an HTTP binding may be provided to provide inband notification and facilitate traversal of firewalls and proxy-based deployments. 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]. Table of Contents Status of this Memo ........................................... 1 Abstract....................................................... 2 Conventions used in this document.............................. 2 Table of Contents.............................................. 2 1. Introduction................................................ 3 2. Connectivity Models......................................... 3 2.1. In-Response Connectivity............................... 3 2.1.1. In-band Connectivity.............................. 4 Maes Expires û January 2006 [Page 2]
<Lemonade HTTP Binding> July 2005 2.1.2. Out-of-band Connectivity........................... 5 3. Using HTTP as a binding...................................... 6 A.1. Non-Persistent HTTP for In-response Connectivity Mode 7 A.2. Using Persistent HTTP/HTTPS + Chunked Transfer Encoding for In-band Connectivity Mode ............................ 8 Security Considerations......................................... 9 References......................................................10 Future Work.....................................................11 Version History.................................................11 Acknowledgments.................................................11 Authors Addresses...............................................11 Intellectual Property Statement.................................13 Full Copyright Statement........................................14 1. Introduction As part of the Lemonade work [LEMONADEPROFILE] to define extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at delivering extended functionality for mobile devices with limited resources, Lemonade HTTP binding describes how an HTTP binding may be provided to provide inband notification and facilitate traversal of firewalls and proxy-based deployments; issues identified as critical in [MEMAIL] and [OMA-ME-RD]. A regular HTTP connection can be used to support in-response connectivity mode for a Lemonade session, whereas a persistent HTTP connection can be used to support inband connectivity. 2. Connectivity Models [NOTIFICATIONS] describes notifications and filtering extensions to IMAP. This sections reviews them and position the use of HTTP binding in such a context. There are three connectivity models, depending on the capabilities of the server, the client, and the connection available between them. These models include in-response, in-band, and out-of-band. It is explicitly stated in what situations these three connectivity models arise. 2.1. In-Response Connectivity The in-response binding scenario is the most basic one and implements the poll model. In this case the client initiates the commands to the server and the server responds to client commands with events. In this case there is no need for a persistent connection between the Maes Expires û January 2006 [Page 3]
<Lemonade HTTP Binding> July 2005 client and the server. The client opens a connection only when it needs to send commands to the server, and that is the only time it is notified of new events. +--------+ +++ HTTP, etc. +--------+ | | Command +++ | | | Client |--------------------+++--------------->| | | Device | +++ | Server | | | Response + Event +++ | | | |<-------------------+++----------------| | +--------+ +++ +--------+ Figure 1: In-Response connection Cases of in-response connection: [1] HTTP/HTTPS binding - Server Requires: HTTP/HTTPS listener for IMAP - Client Requires: HTTP/HTTPS client with IMAP processing [2] TCP Binding - Server Requires: IMAP - Client Requires: IMAP + no IDLE 2.1.1. In-band Connectivity The in-band binding scenario corresponds to a reliable push model. In this case the server pushes events to the client whenever they occur. To do so, it must have a reliable means of communication with the client, and the client should be ready to accept such notifications. In this case, there needs to be a persistent connection between the client and the server so that the server can push an event at any time. The client may optionally issue a request to retrieve more information concerning an event. +--------+ OOO TCP, Persistent +--------+ | | Push Event OOO HTTP, etc. | | | Client |<------------------OOO-----------------| | | Device | OOO | Server | | | Optional Request OOO | | | |...................OOO................>| | +--------+ OOO +--------+ Figure 2: In-band Connection Cases of in-band connection: [1] TCP Binding, Always connected, IDLE - Server Requires: IMAP + IDLE - Client Requires: IMAP + IDLE, constant TCP connection [2] Any other persistent two-way connection - Server Requires: IMAP + IDLE on persistent connection (e.g. HTTP/HTTPS) Maes Expires û January 2006 [Page 4]
<Lemonade HTTP Binding> July 2005 - Client Requires: IMAP + IDLE on persistent connection (e.g. HTTP/HTTPS), constant connection Persistent HTTP/HTTPS may sometimes be difficult to achieve with todayÆs intermediaries if the HTTP server does not support HTTP 1.1 correctly or has a very short timeout period for persistent connections. Both connectivity models above (In-response and in-band) involve a maintained data connection with notification exchanged within the IMAP ôbandö (i.e. IMAP exchanges). 2.1.2. Out-of-band Connectivity This case coves notification outside the IMAP ôbandö: - In a different connection - Within the same data connection but outside the IMAP ôbandö The out-of-band binding scenario corresponds to a push model that may be unreliable. In this case the server pushes events to the client whenever they occur, to the best of its ability. To do so, it should be able to send messages to the client without necessarily the need for a persistent connection. However, the out-of-band channel can possibly lose and reorder messages, and there are no timing guarantees. Examples of out-band channels include SMS (and GSMSMS), WAP Push (and WAPWDP), SIP notification and UDP. As in the in-band scenario, the client may optionally open a P-IMAP session over an in-band or in- response connection and send a command as a result of receiving an event. +--------+ Push Event XXX SMS/SIP/MMS/UDP +--------+ | |<--------------XXX---------------------| | | Client | XXX /WAP Push/... | | | Device | In-band or | Server | | | Request +O+ In-response | | | |---------------O+O-------------------->| | +--------+ +O+ +--------+ Figure 3: Out-of-band Connection Cases of out-of-band connectivity: [1] A notification service from the server to the client - Server Requires: A notification generator. - Client Requires: A notification processor. In-band or In-response exchanges are on: - HTTP or HTTPS Maes Expires û January 2006 [Page 5]
<Lemonade HTTP Binding> July 2005 - TCP - Other transport 3. Using HTTP as a binding It is possible to use HTTP/HTTPS as transport protocol for commands between the client and server. To do so, the client must POST an HTTP request to the server, and embed Lemonade commands (commands to em- mail server or submit servers and Lemonade extensions) in the body of the request (GET requests are rejected by the server). The content- type header of the post request must be set to "application/vnd.lemonade". Multiple Lemonade commands may be included in one POST request. Here is an example of a possible Lemonade HTTP request: POST /lemonadeServletPath HTTP/1.1 <CRLF> Content-Type: application/vnd.lemonade <CRLF> [other headers] <CRLF> <tag> SP <Lemonade command> <CRLF> [<tag> SP <Lemonade command> <CRLF>] - The Lemonade command should be plain text (7bit) and should follow what is specified in section Error! Reference source not found. of this document. - 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. - These are the only HTTP headers required to be sent to the Lemonade servers, but others are acceptable.. 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. This means the client may send a Maes Expires û January 2006 [Page 6]
<Lemonade HTTP Binding> July 2005 command that generates a BAD or NO IMAP response and still get a 200 response code. 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. Often, in this case, the server cannot send back the expected IMAP responses to the commands as defined in this document. If using HTTP as the transport, 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 zipping capability. STARTTLS should not be needed in this case, as it just requires additional overhead without any additional benefit. HTTP can be used in both in-response and in-band modes. Details about these transport modes are given in the following two subsections. A.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, IDLE and other commands that use a continuation response cannot be issued. 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> Maes Expires û January 2006 [Page 7]
<Lemonade HTTP Binding> July 2005 [<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 /lemonadeServletPath 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>] A.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: chunkedContent-Type: text/plain Maes Expires û January 2006 [Page 8]
<Lemonade HTTP Binding> July 2005 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: <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. 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. Security Considerations The protocol calls for the same security requirements for an in- response and inband connectivity mode as IMAP. Maes Expires û January 2006 [Page 9]
<Lemonade HTTP Binding> July 2005 For the outband connectivity mode, servers should use encryption methods for notifications if sensitive information is included in the payload of that notification. HTTPS protocol can be used to provide end-to-end security Proxy-based implementations may still require payload encryption for end-to-end security. It is also recommended that clients be explicitly registered with the server through separate channels / application. Exchanges should then be paired. References [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", draft-ietf-lemonade-profile-XX.txt, (work in progress). [MEMAIL] Maes, S.H., ôLemonade and Mobile e-mail", draft-maes- lemonade-mobile-email-xx.txt, (work in progress). [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., "P Server to Client Notifications and Filtering", draft-ietf-lemonade-server-to- client-notifications-xx.txt, (work in progress). [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). [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 Maes Expires û January 2006 [Page 10]
<Lemonade HTTP Binding> July 2005 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 Future Work TBD Version History Release 01 Detail updates of the text throughout the document following lessons learned so far in P-IMAP 07 [P-IMAP]. 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 Maes Expires û January 2006 [Page 11]
<Lemonade HTTP Binding> July 2005 500 Oracle Parkway Redwood Shores, CA 94065 USA Jia-der Day Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Vida Ha 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 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 Gustaf Rosell Sony Ericsson P.O. Box 64 SE-164 94 Kista, Sweden Tel: +46 8 508 780 00 Jean Sini Symbol Technologies 6480 Via Del Oro San Jose, CA 95119 USA Maes Expires û January 2006 [Page 12]
<Lemonade HTTP Binding> July 2005 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 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 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 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 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. Maes Expires û January 2006 [Page 13]
<Lemonade HTTP Binding> July 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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 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 û January 2006 [Page 14]