Network Working Group L. Nerenberg Internet Draft: IMAP4 Binary Content Extension MessagingDirect Ltd. Document: draft-nerenberg-imap-binary-01.txt November 2000 Expires: May 2001 IMAP4 Binary Content Extension Status of this memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Distribution of this draft is unlimited. 0. Administrivia Changes from version -00 + Renamed CHARALL to BINCHAR. + Changed syntax to "FETCH x BINARY ..." + Defined FETCH BINARY response. + Modified syntax to distinguish it from . + Added examples section. Nerenberg draft-nerenberg-imap-binary-01.txt [Page 1] Internet Draft IMAP4 Binary Content Extension November 2000 1. Abstract This memo defines the BINARY extension to the Internet Message Access Protocol [IMAP4rev1]. It provides a mechanism for IMAP4 clients and servers to exchange certain MIME body parts in a raw binary format, without the use of MIME content transfer encoding. 2. Conventions Used in this Document The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," and "MAY" in this document are to be interpreted as described in [KEYWORD]. In examples, "C:" and "S:" preface lines sent by the client and the server respectively. 3. Overview The MIME extensions to Internet messaging allow for the transmis- sion of non-textual (binary) message content [MIME-IMB]. Since the traditional transports for messaging are not always capable of passing binary data transparently, MIME provides encoding schemes that allow binary content to be transmitted over transports that are not normally capable of doing so. The overhead of MIME encod- ing this content can be considerable in some contexts (e.g. clients connected over slow radio networks). The BINARY extension extends the FETCH command to allow clients to request terminal MIME body parts be sent in a raw, unencoded, for- mat, thus avoiding any content transfer encoding overhead. 4. Framework for the IMAP4 Binary Extension This memo defines the following extensions to [IMAP4rev1]. 4.1. CAPABILITY Identification IMAP4 servers that support this extension MUST include "BINARY" in the response list to the CAPABILITY command. 4.2. FETCH Command Extensions This extension defines two new FETCH command data items. BINARY[<> The binary content of a particular terminal body section. This data item acts as BODY does, with the following excep- tions: The server removes any MIME content transfer encoding from the body part before transmitting it to the client. This content conversion MUST NOT cause a loss of information. If the server is unable to decode the MIME content transfer encoding, it MUST reject the FETCH command with a NO response that includes the "UNKNOWN-TRANSPORT-ENCODING" extended response code. Nerenberg draft-nerenberg-imap-binary-01.txt [Page 2] Internet Draft IMAP4 Binary Content Extension November 2000 Only terminal body parts can be requested. The part specifier MUST NOT refer to non-terminal body parts, or to message head- ers. Servers MUST reject such requests with a BAD response. BINARY.PEEK[<> An alternate form of BINARY[
] that does not implic- itly set the \Seen flag. 4.3. FETCH Response Extensions This extension defines one new FETCH response data item. BINARY[
]<> A expressing the body content of the specified sec- tion after the removal of any content transfer encoding. If the origin octet is specified, this string is a substring of the entire body contents, starting at that origin octet. This means that BODY[]<0> MAY be truncated, but BODY[] is NEVER truncated. 5. Examples The examples in this section are illustrative only; they DO NOT form part of this specification. This example uses a message containing a text/plain body part, fol- lowed by an image/jpeg body part, followed by a multipart/report body part: MIME Content Part# Type ----------------------------------------------- 1 text/plain 2 image/jpeg (BASE64 encoded, encoded size = 30448 octets) 3 multipart/report 3.1 text/plain 3.2 message/delivery-status Here the client requests the image/jpeg part in binary format: C: 1 fetch 1 binary[2] S: * FETCH (BINARY[2] ~{22216} S: <22216 octets of binary data>) S: 1 OK Completed Note the absence of a between the end of the binary data and the closing parenthesis. Also, the size of the string (22216 octets) represents the size of the data after the content transfer encoding has been removed. This is not the same as the size in the BODYSTRUCTURE response (30448 octets) which represents the BASE64 encoded size of the body part. Nerenberg draft-nerenberg-imap-binary-01.txt [Page 3] Internet Draft IMAP4 Binary Content Extension November 2000 If the server does not know how to undo the content transfer encod- ing it issues a failure response: S: 1 NO [UNKNOWN-CONTENT-ENCODING] Unknown encoding for message 1, part 2 A BINARY fetch of the multipart/report is illegal; it contains nested MIME parts: C: 2 fetch 1 binary[3] S: 2 BAD Non-terminal part (3) requested in FETCH BINARY for message 1 For parts with no content transfer encoding, FETCH BODY and FETCH BINARY return identical content: C: 3 fetch 1 body[1] S: * 1 FETCH (BODY[1] {80} S: This is a test message to use in the examples section of the S: IMAP BINARY RFC. S: ) S: 3 OK Completed C: 4 fetch 1 binary[1] S: * 1 FETCH (BINARY[1] ~{80} S: This is a test message to use in the examples section of the S: IMAP BINARY RFC. S: ) S: 4 OK Completed 6. Interoperability Considerations Messaging clients and servers have been notoriously lax in their adherance to the Internet CRLF convention for terminating lines of textual data in Internet protocols. When sending data using the BINARY extension, servers must take care to ensure that non-encoded non-binary body parts are always transmitted using the IMAP4 CRLF line termination syntax, regardless of the underlying storage rep- resentation of the data on the server. While the syntax allows for BINARY fetches of more than one body part in a single command, such use is discouraged. In the event of multiple partial failures, it can be difficult for the client to map specific failures to individual components of the request. Instead, clients SHOULD issue separate FETCH requests for each body part. This extension provides an optimization that is useful in certain specific scenarios. It does not absolve clients from providing basic functionality (content transfer decoding) that should be available in all messaging clients. Clients supporting this exten- sion SHOULD be prepared to provide their own content transfer decoding of data, although they may decide not to retry a FETCH BINARY request with a FETCH BODY request, if that is reasonable in the context of their execution environment. Nerenberg draft-nerenberg-imap-binary-01.txt [Page 4] Internet Draft IMAP4 Binary Content Extension November 2000 7. Formal Protocol Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as used in [IMAP4rev1]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. This syntax extends the grammar specified in [IMAP4rev1]. BINCHAR ::= <0x00 - 0xff> fetch_att =/ "BINARY" [".PEEK"] section_binary ["<" number "." nz_number ">"] literal8 ::= "~{" number "}" CRLF *BINCHAR ;; represents the number of BINCHAR octets ;; in the response string. resp_code_text =/ "UNKNOWN-TRANSPORT-ENCODING" section_binary ::= "[" [ (nz_number *["." nz_number] ] "]" ;; MUST refer only to a terminal mime body part. 8. References [IMAP4rev1] Crispin, M., "Internet Message Access Protocol Version 4rev1," RFC2060, University of Washington, December 1996 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 9, RFC2119, March 1997 [MIME-IMB] Freed, N., N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies," RFC2045, November 1996. 9. Security Considerations Sending binary data to servers and clients that are expecting well- formed non-binary input is a method commonly used to attempt to bypass security. The IMAP4 BINARY extension is only initiated at a co-operating client's request, therefore the transmission of binary content as defined in this memo should not affect legacy clients that may be unable to properly cope with such binary content. A new protocol syntax has been introduced to further distinguish between and data. Nerenberg draft-nerenberg-imap-binary-01.txt [Page 5] Internet Draft IMAP4 Binary Content Extension November 2000 10. Authors' Address Lyndon Nerenberg MessagingDirect Ltd. Suite 900 10117 - Jasper Avenue Edmonton, Alberta Canada T5J 1W8 Email: lyndon@messagingdirect.com Nerenberg draft-nerenberg-imap-binary-01.txt [Page 6]