Lemonade Internet Draft: LCONVERT S. H. Maes Document: draft-maes-lemonade-lconvert-00 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 LCONVERT Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Maes [Page 1] July 2005 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 LCONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile setting, aimed at allowing adaptation and transcoding of attachments as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings. 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. Relation with other E-mail specifications................ 3 3. Interactions between the Client and Server when supporting LCONVERT.................................................... 4 4. The CAPABILITY Command................................... 4 5. LCONVERT & UID LCONVERT.................................. 4 Maes Expires – January 2006 [Page 2] July 2005 Security Considerations..................................... 7 References.................................................. 7 Normative Appendices........................................ 8 A. Security Issues for Proxy-Based Implementations....... 8 B. LCONVERT transcoding parameters....................... 9 Future Work................................................. 9 Version History............................................. 9 Acknowledgments.............................................10 Authors Addresses...........................................10 Intellectual Property Statement.............................12 Full Copyright Statement....................................12 1. Introduction LCONVERT is based on IMAPv4 Rev1 [RFC3501]. It defines additional enhancements for optimization in a mobile setting: extensions to the IMAPv4 Rev1 protocol [RFC3501] that allows adaptation and transcoding of attachments as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings. These are important features required in particular to support mobile email use cases [MEMAIL], [OMA-ME-RD]. A server that supports LCONVERT can convert attachments to other formats to be viewed on a mobile device. The client can explicitly request a particular conversion. The server complies on a best effort basis. When not possible, the server determines based on its own strategy (e.g. based on knowledge of the client as discussed hereafter) how to convert. If the server knows the characteristics of the device or can determine them (out of scope of LCONVERT), the attachments can also be optimized for the capabilities of the devices (e.g. form factor of pictures). See discussion in Appendix B. This is a recommended server behavior. 2. Relation with other E-mail specifications The Lemonade Profile [LEMONADEPROFILE] specifies the Lemonade Pull Model that governs the exchanges among mail servers or between desktop mail client and mail servers. Lemonade investigates adding mobile optimizations for the next version of the profile. LCONVERT should be seen as a way to address the issues of mobile optimization and an input to the Lemonade Profile work. It addresses the topic of attachment conversions identified by the Lemonade work as critical for mobile email. Maes Expires – January 2006 [Page 3] July 2005 LCONVERT does not address conversion and streaming of media as also identified of interest by lemonade. This has not been identified as relevant to mobile e-mail [MEMAIL] and [OMA-ME-RD]. Clients and servers MAY support other Lemonade extensions and behaviors. This document assumes that clients MUST be compliant to LCONVERT when it decides to use this command. The server that claims support of LCONVERT MUST be compliant to LCONVERT for its exchanges with the mobile client. 3. Interactions between the Client and Server when supporting LCONVERT A compliant server must support all IMAPv4Rev1 commands from client devices following the syntax defined in [RFC3501]. Thus, a client may issue any existing IMAP commands to the server, and both the server and client must behave as specified in [RFC3501]. 4. The CAPABILITY Command The CAPABILITY command is defined in RFC3501, section 6.1.1. The client sends a CAPABILITY command so it can query the server to find out what commands it supports. In RFC3501, the IMAP server is allowed to specify additional capabilities not included in that specification. A server that supports LCONVERT and its requirements MUST list that it supports LCONVERT. A server can also enumerate individually the other commands that it supports. capability_cmd = tag SP "CAPABILITY" Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT Responses: REQUIRED untagged response: CAPABILITY Result: OK - capability completed BAD - command unknown or arguments invalid Example: A server that implements LDELIVER. C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LCONVERT S: a001 OK CAPABILITY completed 5. LCONVERT & UID LCONVERT LCONVERT and UID LCONVERT are used for attachments conversion. The client sends one message sequence number or UID, the body part to retrieve, and gives the mime-type and subtype to convert the attachment to. When specifying the body part, the client can specify Maes Expires – January 2006 [Page 4] July 2005 to peek only at the message and/or to return only certain bytes of the converted part. Optionally, after the mime-type and subtype, the client can specify additional parameters specific to the target content type, such as CHARSET if the target content-type is TEXT/plain and optionally content-transfer-encoding. See Appendix B for a description of LCONVERT parameters. The server is not required to respect those parameters. Indeed, the server may know a priori information about the client obtained through a different mechanism outside the scope of LCONVERT (e.g. dynamically through device description mechanisms or when the device was associated to the account). These preferences may be used to predefine what conversions are possible. Ideally the client should request the same conversions. In addition, this information may also allow attachment adaptation (e.g. picture form factor) instead of solely format conversion. As a response to an LCONVERT command, the server gives an untagged LCONVERT response which has syntax similar to an untagged FETCH response. The LCONVERT response includes a BODY[] data item, a BODYPARTSTRUCTURE data item, and a UID data item if the command is UID LCONVERT. The BODYPARTSTRUCTURE data item is introduced by the LCONVERT command. It follows the exact syntax specified in BODYSTRUCTURE, but contains information for only the converted part. All information contained in BODYPARTSTRUCTURE pertains to the state of the part after it is converted, such as the converted mime-type, sub-type, size, or charset. The client must respect any values in this BODYPARTSTRUCTURE, meaning if it specifies a different content- transfer-encoding value, the client must decode the response based on that encoding. It must also respect the required parameter values pertaining to the specific target content-type (for example, CHARSET if target content-type is TEXT/plain). lconvert_cmd = tag SP "LCONVERT" message-sequence-number SP "BODY" [".PEEK"] "[" part-id "]" ["<" byte-start "." max-bytes ">"]SP "as" SP mime-type "/" subtype [parameter-list] parameter-list= ";" parameter "=" parameter-value [parameter-list] Valid States: SELECTED Responses: untagged responses: LCONVERT Untagged LCONVERT response = "*" SP message-sequence-number SP "LCONVERT" SP "(" "BODYPARTSTRUCTURE[" partnum "]" SP bodystructureOfPart SP "BODY[" partnum "]" ["<" origin_octet ">"] SP "{" num-bytes "}" CRLF bytes CRLF ")" Result: OK - lconvert completed NO - lconvert error: can't perform the command BAD - command unknown or arguments invalid Maes Expires – January 2006 [Page 5] July 2005 Note: as DEFAULT/DEFAULT MAY be used to request conversion as decided as default by the server (in general for the media type or based on knowledge of the target device, possibly based on the user preferences logged with the server) Example: The client fetches an attachment in the message with the message sequence number of 2 in the Inbox and asks to have that attachment converted to pdf format. The client does not request a content-transfer-encoding, and in this case, the server uses the same content-transfer-encoding to encode the converted response. C: a001 LCONVERT 2 BODY[3] as application/pdf S: * 2 LCONVERT (BODYPARTSTRUCTURE[3] ("APPLICATION" "PDF" () NIL NIL "Base64" 2135 NIL NIL NIL) BODY[3] {2135} ) S: a001 OK LCONVERT COMPLETED Example: The client requests for conversion of a text/html section as text/plain and asks for a charset of us-ascii and a 7bit encoding. The server cannot respect the charset request because there are non- us-ascii characters in the html code. Thus, in the untagged response, the server returns the charset of UTF-8 and a 8bit encoding, along with the converted text. C: a001 LCONVERT 2 BODY[3] as text/plain;charset="us-ascii"; content-transfer-encoding="7bit" S: * 2 LCONVERT (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL NIL "Base64" 2135 181 NIL NIL NIL) BODY[3] {2135} the document in text/plain format ) S: a001 OK LCONVERT COMPLETED Example: The client requests for conversion of a text/html section as text/plain, but only wants 1000 bytes, starting from byte 2001. C: a001 LCONVERT 2 BODY[3]<2001.1000> as text/plain;charset="us- ascii";content-transfer-encoding="7bit" S: * 2 LCONVERT (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL NIL "Base64" 2135 181 NIL NIL NIL) BODY[3]<2001> {135} bytes 2001 - 2135 of the document in text/plain format ) S: a001 OK LCONVERT COMPLETED luidconvert_cmd = tag SP "UID" SP "LCONVERT" uid SP lconvert-listitem-list SP "as" SP mime-type "/" subtype [parameter-list] Valid States: SELECTED Responses: untagged responses: UID LCONVERT Maes Expires – January 2006 [Page 6] July 2005 Untagged UID LCONVERT response = "*" SP message-sequence-number SP "LCONVERT" SP "(" "UID" SP uid SP "BODYPARTSTRUCTURE[" partnum "]" SP bodystructureOfPart SP "BODY[" partnum "]" SP "{" num- bytes "}" CRLF bytes CRLF ")" Result: OK - luidconvert completed NO - luidconvert error: can't perform the command BAD - command unknown or arguments invalid Example: The client fetches an attachment in the message with UID 120 (and message sequence number 2) in the Inbox and asks to have that attachment converted to pdf format. C: a001 UID LCONVERT 120 BODY[3] as application/pdf S: * 2 LCONVERT (UID 120 BODYPARTSTRUCTURE[3] ("APPLICATION" "PDF" () NIL NIL "Base64" 2135 NIL NIL NIL) BODY[3] {2134} ) S: a001 OK UID LCONVERT COMPLETED Security Considerations When an implementation is proxy-based, this may create new security issues. These issues are discussed in detail in Appendix C, because the issues are dependent on the implementation of this protocol rather than inherent to the protocol itself. On bandwidth limited mobile networks where users pay per data volumes, spam may become an important issue. It can be mitigated with appropriate filters and server-side spam prevention tools. These are of course outside the scope of LCONVERT. 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). [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, (Work in progress). http://www.openmobilealliance.org/ [OMA-STI] Open Mobile Alliance, Standard Transcoding Interface Specification, version 1.0, [Work in progress] Maes Expires – January 2006 [Page 7] July 2005 (http://member.openmobilealliance.org/ftp/Public_documents/BAC/STI /Permanent_documents/OMA-STI-V1_0-20050209-D.zip). [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 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 Normative Appendices A. Security Issues for Proxy-Based Implementations In some implementations, the client may connect to a proxy that sits in an operator network, but the backend email storage server sits in a separate enterprise network. The enterprise network is assumed to be secure, but the operator network may not be trusted. If unencrypted information lies in the operator network, that information is vulnerable to attacks. If the LCONVERT extensions are all implemented in the enterprise network, then the proxy on the carrier should be an encrypted SSL pass-through proxy. The proxy is unaware of the encryption keys and thus cannot encrypt any data. Without the encryption key, this proxy cannot see any of the information sent from the client, nor can it send any bogus commands to the backend enterprise email server to corrupt the user's mailbox. The additional cost for this design is that the backend enterprise email server and the client devices must have additional processing to handle this encryption. If the LCONVERT compliant server is implemented as a backend IMAP server with additional command processing done on the proxy, there are more complex security issues. This proxy must be able to send commands to the backend server to accomplish its tasks, as well as read information coming from the backend server. An attacker thus can send commands to the backend to change the state of the mail storage, possibly corrupting it. In addition, it can read responses from the mail server that might contain confidential email information. This proxy may also send bogus responses back to the client. Clearly, this setup is not an ideal issue and many Maes Expires – January 2006 [Page 8] July 2005 complications that make this problem complex to solve. The suggestion recommended is to remedy the problem of unencrypted, untagged FETCH responses that may contain confidential information. Encrypted responses should be used in place of any untagged FETCH responses, which contain encrypted message information to be passed through the proxy on the operator network. The key exchange for encryption should not occur through the proxy. It has to be done through another channel: manually entered by user (e.g. password), or via an HTTP SSL request to the enterprise server. Any other additional server responses containing sensitive information (passwords, etc.) should be encrypted. B. LCONVERT transcoding parameters LCONVERT servers MAY support additional transcoding parameters for each media type. All LCONVERT compliant servers MUST minally support recognition of charset and encoding parameters for text/* mime types, although they may decline to honor some requests. For media types other than text, it is beyond the scope of this document to define conversion parameters. In general however, LCONVERT compliant servers MAY choose to support additional parameters, and if so, they SHOULD follow the OMA STI 1.0 spec [OMA-STI] adopting the same parameter names as defined in second 5.2.4 and above for the most popular image/*, video/*, and audio/* codecs As an example, in section 5.2.6.2 of [OMA-STI], the parameters "width" and "height" are defined. The following example illustrates how these OMA STI parameters MUST be used with XCONVERT. C: a001 UID LCONVERT 100 BODY[2] as image/jpg;width=128;height=96 S: * 2 LCONVERT (UID 100 BODYPARTSTRUCTURE[2] ("IMAGE" "JPG" () NIL NIL "Base64" 4182 NIL NIL NIL) BODY[2] {4182} ) S: a001 OK UID LCONVERT COMPLETED Future Work TBD Version History Release 00 Initial release published in June 2005 Maes Expires – January 2006 [Page 9] July 2005 Acknowledgments The authors want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of LDELIVER and its early introduction as XDELIVER 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 Vida Ha Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Wook-Hyun Jeong Samsung Electronics,CO., LTD Maes Expires – January 2006 [Page 10] July 2005 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 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, Maes Expires – January 2006 [Page 11] July 2005 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Full Copyright Statement Copyright (C) The Internet Society 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any Maes Expires – January 2006 [Page 12] July 2005 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 13]