Lemonade Internet Draft: CONVERT S. H. Maes Document: draft-ietf-lemonade-convert-00 R. Cromwell (Editors) Expires: April 2006 October 2005 CONVERT 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. Abstract CONVERT 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. Maes [Page 1]
<CONVERT> October 2005 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....................................................... 1 Conventions used in this document.............................. 1 Table of Contents.............................................. 2 1. Introduction................................................ 2 2. Relation with other E-mail specifications................... 3 3. Interactions between the Client and Server when supporting CONVERT........................................ 4 4. Discovery with the CAPABILITY and GETANNOTATION Commands.... 4 4.1. CAPABILITY............................................. 4 4.2. GETANNOTATION.......................................... 4 5. CONVERT BODY and BINARY data item extension................. 5 6. FETCH response extensions................................... 7 7. Status responses, Response code extensions.................. 7 8. Formal Syntax............................................... 8 Security Considerations........................................ 9 References..................................................... 9 Normative Appendices...........................................10 A. Security Issues for Proxy-Based Implementations..........10 B. CONVERT transcoding parameters...........................11 Future Work....................................................11 Version History................................................11 Acknowledgments................................................12 Authors Addresses..............................................12 Intellectual Property Statement................................12 Full Copyright Statement.......................................13 1. Introduction CONVERT is based on IMAPv4 Rev1 [RFC3501]. It defines additional enhancements for optimization in a mobile setting: extensions to the Maes Expires û April 2006 [Page 2]
<CONVERT> October 2005 IMAPv4 Rev1 protocol [RFC3501] that allows adaptation and transcoding of body parts 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 CONVERT can convert leaf body parts 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 CONVERT), 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. CONVERT 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. CONVERT 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 CONVERT when it decides to use this extension. The server that claims support of CONVERT MUST be compliant to CONVERT for its exchanges with the mobile client. CONVERT depends on the ANNOTATEMORE extension [ANNOTATEMORE] to support discover of supported conversion formats. Maes Expires û April 2006 [Page 3]
<CONVERT> October 2005 3. Interactions between the Client and Server when supporting CONVERT 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]. In addition, to use CONVERT, the client and server MUST support the IMAP Binary specification [RFC3516]. This document does not specify how conversions are to be done by the server. It is however noted that the conversion MUST NOT affect the document stored in the message storage server in order to remain accessible unaffected through other clients that do not request conversion as well as in order to allow replies or forward of the documents as they were originally received on the server. 4. Discovery with the CAPABILITY and GETANNOTATION Commands 4.1. CAPABILITY 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 CONVERT and its requirements MUST list that it supports CONVERT. 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 CONVERT BINARY S: a001 OK CAPABILITY completed 4.2. GETANNOTATION To determine which conversions are supported, mailbox annotations are used. For each mime-type that the client is interested in, it MAY determine which conversions are supported. For any proposed conversion, the client MAY discover a list of optional parameters that the conversion SHOULD accept. MIME type/subtype are mapped to a hierarchy under the root ô/convertö. For each mime type under Maes Expires û April 2006 [Page 4]
<CONVERT> October 2005 ô/convertö, a value for ôtypes.sharedö SHOULD exist which is a semicolon separated list of output formats. Example: Discover all image conversions C: a GETANNOTATION "INBOX" "/convert/image/*" "types.shared" S: * ANNOTATION "INBOX" "/convert/image/jpeg" ("types.sharedö "image/jpeg;image/png;image/gif;image/wbmpö) S: a OK GETANNOTATION complete For a given conversion, optional transcoding parameters MAY be present. These are mapped into a value ôparams.sharedö under ô/convert/sourcetype/destinationtypeö. Example: Discover optional parameters for image/jpeg -> image/gif. C: a GETANNOTATION "INBOX" "/convert/image/jpeg/image/gif" "params.shared" S: * ANNOTATION "INBOX" "/convert/image/jpeg/image/gif" ("params.sharedö "width;height;depth;interlacedö) S: a OK GETANNOTATION complete A client MAY use these values to check whether or not a desired conversion is possible, or it may present the parameters as a GUI preferences pane for the user to customize. A baseline set of register transcoding parameter names should be standardized (see [OMA-STI]) in the future, and it is beyond the scope of this spec to allow the client to discover the underlying legal values that these parameters may take. 5. CONVERT BODY and BINARY data item extension CONVERT is a FETCH extension used to transcode the media type of a leaf MIME part into another media type, and/or the same media type, with different encoding parameters. It adds new options to the section-spec part of the BODY data item, a new FETCH response data item BODYPARTSTRUCTURE, and new response codes. It is also expected to work with IMAP BINARY data item extension, whose grammar is modified as well. CONVERTÆs syntax is modeled after the HEADER.FIELDS syntax in RFC3501, and is generally structured as: BODY[section-part.CONVERT[.STRICT] (ômedia typeö ôsubtypeö (parameters))] BODY.PEEK[section-part.CONVERT[.STRICT] (ômedia typeö ôsubtypeö (parameters))]<partial> Maes Expires û April 2006 [Page 5]
<CONVERT> October 2005 BINARY[section-part.CONVERT[.STRICT] (ômedia typeö ôsubtypeö (parameters))]<partial> BINARY.PEEK[section-part.CONVERT[.STRICT] (ômedia typeö ôsubtypeö (parameters))]<partial> BINARY.SIZE[section-part.CONVERT[.STRICT] (ômedia typeö ôsubtypeö (parameters))]<partial> Example: The client fetches body part section 3 in the message with the message sequence number of 2 and asks to have that attachment converted to pdf format. C: a001 FETCH 2 BODY[3.CONVERT (ôAPPLICATIONö ôPDFö)] S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("APPLICATION" "PDF" () NIL NIL "Base64" 2135 NIL NIL NIL) BODY[3] {2135} <the document in .pdf format> ) S: a001 OK FETCH COMPLETED Example: The client requests for conversion of a text/html section as text/plain and asks for a charset of us-ascii. 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 utilizes a content transfer encoding capable of representing the full 8-bit range, along with the converted text. C: a001 FETCH 2 BODY[3.CONVERT (ôtextö ôplainö (ôcharsetö ôus- asciiö))] S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL NIL "Base64" 2135 181 NIL NIL NIL) BODY[3] {2135} the document in text/plain format ) S: a001 OK FETCH 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 FETCH 2 BODY[3.CONVERT (ôTEXTö ôPLAINö (ôCHARSETö ôus- asciiö))]<2001.1000> S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL NIL "7bit" 2135 181 NIL NIL NIL) BODY[3]<2001> {135} bytes 2001 - 2135 of the document in text/plain format ) S: a001 OK FETCH COMPLETED The server is not required to respect a particular transcoding request or its request parameters unless the STRICT qualifier is used, although it MAY try to make a best effort to fulfill that Maes Expires û April 2006 [Page 6]
<CONVERT> October 2005 request if it is omitted. Indeed, the server may know a priori information about the client obtained through a different mechanism outside the scope of CONVERT (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. 6. FETCH response extensions The BODYPARTSTRUCTURE data item is introduced when using the CONVERT extension. It follows the exact syntax specified in the [RFC3501] BODYSTRUCTURE data item, 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 the return values and not assume the conversion request succeeds. 7. Status responses, Response code extensions Some transcodings may require parameters. If a transcoding request is sent for a format which requires parameters, the server can reply with a BAD response. Likewise, malformed mime types may also generate BAD responses. If the server if unable to perform the requested conversion because a resource is unavailable (internal error, transcoding service down) than a BAD response should be returned. If a request is denied because of an operational error, such as lack of disk space, or because the requested conversion for some reason cannot be performed, and there is no fallback for this particular device (such as the case where a proprietary document format has no existing transcoding implementation, and the server recognizes that the client has no default viewer for it), the server SHOULD return a NO response. Otherwise, the server should return an OK response. The client in general can tell from the BODYPARTSTRUCTURE response whether or not its request was honored exactly, but may not know exactly why it differents. The following extension response codes are provided for OK and NO responses to disambiguate those situations, or warn about possible important data loss. Maes Expires û April 2006 [Page 7]
<CONVERT> October 2005 INFORMATIONLOSS û the conversion was satisfied for conversion request, but it may have resulted in the loss of important data (primarily of use for loss of text data, since richmedia is often compressed with loss) BADPARAMETERS ô(ô convert-params ô)ö û the listed parameters were not understood, or could not be honored for the reasons noted in section- text. In particular, a CONVERT.STRICT request may be fail because the server has no way to honor it. SERVEROVERRIDE û the server override the request because it determined it could substitute a better one based on preferences, device capability knowledge, or server policy. If CONVERT.STRICT is used, the server may not return SERVEROVERRIDE. It must either honor the request, or fail. 8. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the Core Rules defined in that document. This syntax augments the grammar specified in [RFC3501] and [RFC3516]. In the ABNF section-msgtext grammar in section 9 of [RFC3501], Section-msgtext is hereby amended to read: section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list / "TEXT" / ôCONVERTö SP convert-params convert-params = "(" (media-basic / default-conversion) [SP "(" transcoding-params ")"] ")" transcoding-params = transcoding-param-name SP transcoding-param- value *(SP transcoding-param-name SP transcoding-param-value) transcoding-param-name = string transcoding-param-value = string default-conversion = "NIL" "NIL" In the ABNF syntax ôsection-binaryö of [RFC3516], is amended to: section-binary = "[" [section-part [ô.CONVERTö[.STRICT] SP convert- params] "]" Maes Expires û April 2006 [Page 8]
<CONVERT> October 2005 Security Considerations It is to be noted that some conversions may present security threatens (e.g. converting a document to an damaging executable). Clients should be careful when requesting conversions or processing transformed attachments. Servers should avoid dangerous conversions if possible. It may of interest to consider, when possible, server- side verification of the converted attachments before providing to the server. 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 CONVERT. It is also recommended that clients be explicitly registered with the server through separate channels / application. Exchanges should then be paired. References [ANNOTATEMORE] Daboo, C., "IMAP ANNOTATEMORE Extension" , draft-daboo-imap-annotatemore-07, 2005. [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] (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). Maes Expires û April 2006 [Page 9]
<CONVERT> October 2005 [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 CONVERT extensions are all implemented in the enterprise network, then the proxy on the carrier should be an encrypted SSL pass-through proxy. SSL ensures confidentiality and integrity of the proxied datastream, ensuring that the proxy cannot monitor the content of messages, nor inject commands to modify or corrupt the 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 the overhead of SSL. If the CONVERT 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 who compromises the proxy 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 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 Maes Expires û April 2006 [Page 10]
<CONVERT> October 2005 via an HTTP SSL request to the enterprise server. Any other additional server responses containing sensitive information (passwords, etc.) should be encrypted. It is beyond the scope of this document to define the implementation of transcoding services. In general, it is recommended that they reside within the same domain as the IMAP server, and are not performed by third party services, which may compromise the privacy of the data being transcoded. B. CONVERT transcoding parameters CONVERT servers MAY support additional transcoding parameters for each media type. All CONVERT compliant servers MUST minally support recognition of charset 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, CONVERT 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 FETCH 100 BINARY[2.CONVERT (ôIMAGEö ôJPGö (ôWIDTHö ô128ö ôHEIGHTö ô96ö))] S: * 2 FETCH (UID 100 BODYPARTSTRUCTURE[2] ("IMAGE" "JPG" () NIL NIL "8bit © 4182 NIL NIL NIL) BINARY[2] ~{4182} <this part of a document is a rescaled image in JPG format with width=128, height=96.> ) S: a001 OK UID FETCH COMPLETED Future Work Standardize baseline set of conversions which SHOULD be supported for Lemonade Profile, as well as parameters. Version History Release 00 Initial release published in October 2005 based on draft-maes- lemonade-lconvert-00 and the comments received at the London face to face meeting end of September 2005. Maes Expires û April 2006 [Page 11]
<CONVERT> October 2005 Acknowledgments The authors want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of CONVER and its early introduction P-IMAP [P-IMAP]. In particular, this includes the authors of the LCONVERT draft (draft-maes-lemonade-lconvert-00): Rafiul Ahad û Oracle Corporation, Eugene Chiu û Oracle Corporation, Ray Cromwell û Oracle Corporation, Jia-der Day û Oracle Corporation, Vi Ha û Oracle Corporation, Wook-Hyun Jeong û Samsung Electronics Co. LTF, Chang Kuang û Oracle Corporation, Rodrigo Lima û Oracle Corporation, Stephane H. Maes û Oracle Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini û Symbol Technologies, Sung-Mu Son û LG Electronics, Fan Xiaohui - CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC). 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 Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA 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. Maes Expires û April 2006 [Page 12]
<CONVERT> October 2005 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 (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 û April 2006 [Page 13]
