Internet Draft: IMAP Extension for CONVERSION M. Wener Document: draft-wener-lemonade-conversion-00.txt Nokia, Inc. Expires: August 2005 February 2005 IMAP Extension for Body Part Conversion Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I 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." 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 This document describes an IMAP extension that allows a client to convert and retrieve message MIME parts on demand. The conversion would be from one Content-Type to another. The client can discover the conversion set the server supports. It is assumed that there are two distinct phases: one, server conversion capability discovery, and two, client retrieval of a converted MIME part. In addition to MIME type conversion this document allows for compressed body part retrieval as a special case of conversion. 1. Introduction and Overview The assumption is that the client knows best what body part needs to be converted and what the target should be. Also, the client knows best when it needs a particular body part converted. The set of goals being met by this document are: 1) To give the client maximum control and choice. 2) Avoid having the server do unrequired conversions. Conversions should be on client demand. 3) Avoid verbose communication of large capability sets. The client should not be burdened by information that it is not interested in. In pursuit of these goals there are two main areas of functionality specified: discovery and retrieval. Discovery is the act of the client finding out what is a legal conversion. Retrieval is the client obtaining the converted bytes. Discovery is accomplished via a new server annotation entry. The entry will allow the advertisement of range domain mappings. The client uses the GETANNOTATION command to obtain a subset of mappings that it is interested in. These mappings are read-only to all clients. Retrieval is accomplished by use of the existing FETCH command. The FETCH command has new modifiers used to indicate that the body part is to be converted when retrieved. A server supporting the conversion capability will advertise this via the CONVERSION capability string returned in all CAPABILITY command responses. In addition the server MUST support the annotate more extension [ANNOTATEMORE]. 2. Conversion Capability Discovery The set of legal conversions a server supports are advertised with a set of server annotations. The syntax and form of these entries are as defined in the annotate more specification [ANNOTATEMORE]. The server entries defined in ANNOTATEMORE are extended with the entries defined in the following section. 2.1 Entries These entries are used when the mailbox name argument for the GETANNOTATION command is the empty string. /conversion The existence of this entry indicates that the server supports some type of conversion. <> /conversion/ A conversion can be viewed as a mapping from a domain to a range. The domain is the set of MIME types that can be converted. The range is the set of MIME types that a member of the domain can be converted to. Each entry in this set is a member of the domain of legal conversions. If a server has an entry in this item the server can legally convert from this MIME type to some other MIME type. The range MIME type is indicated via the range attribute. /conversion/compress Server supports the compression of MIME body parts as part of the general conversion support. The supported algorithm is specified with the "value" attribute. 2.2 Attributes The attributes defined are the same as those defined in the annotate more specification except for the /conversion/ entry. The "value" entry is replaced with the "range" entry. range A semi-colon separated list of MIME types. This list is the set of MIME types that this entry may be converted to. 2.3 Conversion Entry Discovery The GETANNOTATION command as defined in the annotate more specification is used to retrieve conversion information. The SETANNOTATION command is not supported. Example: C: a GETANNOTATION "" "/conversion/application/pdf" "range.shared" S: * ANNOTATION "" "/conversion/application/pdf" ("range.shared" "test/plain;text/html") S: a OK GETANNOTATION complete 3. Converted Byte Retrieval 3.1 FETCH Command Modification Result: OK - Conversion fetch completed NO - fetch error: can't convert that data, or illegal body section specifier. The FETCH command is modified by adding a new modifier. The modifier when present means the server should check to see if it is a legal conversion as per what it has advertised via the server annotation entry. If it is not legal a NO response is generated. If it is a legal conversion then the converted bytes are generated and sent back subject to the CONVERSION data item. BODY.CONVERT[
]<> Retrieve the converted bytes of the body part specified by the section. The retrieval is subject to partial retrieval as per the partial byte specification. BODY.CONVERT.PEEK[
]<> A form of BODY.CONVERT that does not set the \Seen flag. BODY.CONVERT.SIZE[
] A form of BODY.CONVERT that returns the estimated converted size. This is an estimate and the client MUST NOT rely on this size as an exact size. This MUST NOT set the \Seen flag. CONVERSION This is used to pass parameters the server may need to perform the conversion. There is a single required parameter. The first parameter MUST indicate a fully specified MIME Content Type. The Content Type is the Content Type to convert the body part to. Additional parameters MAY be specified. << TBD: but the idea is that these would be the parameters that may be needed for more complex parametrically driven conversions>> The values passed in this data item are advertised by the sever via the server annotation entries. A single CONVERSION data item MUST be specified if there are any BODY.CONVERT data items in the fetch command. The single CONVERSION item MUST apply to all BODY.CONVERT data items in the command. <> Example: C: 1 UID FETCH 678 (BODY.CONVERT[1.3] CONVERSION (text/plain) S: * 4 FETCH (UID 678 BODY.CONVERT[1.3] {567} S: ... S: ) S: 1 OK FETCH Completed Example: C: 1 UID FETCH 678 (BODY.CONVERT.SIZE[1.3] CONVERSION (text/plain) S: * 4 FETCH (UID 678 BODY.CONVERT[1.3] 600) S: 1 OK FETCH Completed 3.2 FETCH Response Additions Two new response data items are defined. BODY.CONVERT[
]<> This response has the same form and function as the BODY[] response defined in in IMAP4Rev1 [RFC3501]. The only difference is that the literal contains the converted body part. It has the Content-Type specified by the CONVERSION FETCH command data item. BODY.CONVERT.SIZE[
] A numeric value providing the estimated size of the entire body part after conversion. 3.3 ILLEGALCONVERSION Response Code If the client asks for a conversion that the server does not support the tagged response to the overall command will be NO and the response MUST contain the ILLEGALCONVERSION Response Code. The response code MUST prefix any text in the NO response. This failure could be for any one or more of the messages in the sequence number or UID set passed to the command. Example: C: 2 FETCH 5,6 (BODY.CONVERT[1.2] CONVERSION (text/plain) S: * 6 FETCH (BODY.CONVERT[1.2] {567} S: ... S: ) S: 2 NO [ILLEGALCONVERSION] FETCH Failed Conversion The intent is for the client to avoid getting this response code by using discovery to determine if the server supports a particular conversion. 4. Body Part Compression It is recognized that compression is a special case for conversion. Body part compression can be obtained very simply by creating a keyword to replace or extend the Content Type parameter in the CONVERSION data item. The keyword used to indicate compression is "compress". If the compress keyword is specified then the body part is retrieved in a in a compressed form. It MAY or MAY NOT be converted when compressed. Example: C: 3 FETCH 8 (BODY.CONVERT[1.2] CONVERSION (text/plain compress) S: * 6 FETCH (BODY.CONVERT[1.2] {567} S: ... S: ) S: 3 OK FETCH Completed To retrieve multiple mail messages in a compressed form with no conversion. Example: C: 4 FETCH 1:5 (BODY.CONVERT[] CONVERSION (compress) S: * 1 FETCH ... S: * 2 FETCH ... S: * 3 FETCH ... S: * 4 FETCH ... S: * 5 FETCH ... S: 4 OK FETCH Completed 5. Formal Syntax <> 6. Author Michael J. Wener Nokia, Inc. EMail: Michael.Wener@Nokia.com 7. 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. 8. 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." References [ANNOTATEMORE] Daboo, C., "IMAP ANNOTATEMORE Extension" , draft-daboo-imap-annotatemore-07, 2005. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.