Network Working Group Lyndon Nerenberg Internet Draft: IMAP4 Binary Content Extension MessagingDirect Ltd. Document: draft-nerenberg-imap-binary-00.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 I need to define "terminal" (as in "terminal MIME body part"). 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. Nerenberg draft-nerenberg-imap-binary-00.txt [Page 1]
Internet Draft IMAP4 Binary Content Extension November 2000 3. Overview The MIME extensions to Internet messaging allow for the transmis- sion of non-textual (binary) message content [MIME]. Since the traditional transports for messaging are not always capable of passing binary data transparently, MIME provides encoding schemes that allow binary ("8 bit") content to be transmitted over trans- ports that are not normally capable of doing so. As the size of binary message attachments increases, the overhead of MIME encoding this content can be substantial, especially for IMAP4 clients connecting over slow (e.g. radio) networks. The BINARY extension to IMAP4 extends the FETCH command to allow the client to request terminal MIME body parts be sent in a raw, unencoded, format. 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 BINARY Extension to the FETCH Command The FETCH command is extended to allow a client to specify that a terminal MIME body part be transmitted as a raw (unencoded) octet stream: C: 0 FETCH 1 BODY[x.y.BINARY] This variant of the FETCH command retrieves the terminal MIME body part x.y as a "literal8" string. The server removes any MIME con- tent transfer encoding from the body part before transmitting it to the client. This content conversion MUST NOT cause a loss of infor- mation. If the server is unable to decode the MIME content transfer encoding of the requested body part it MUST reject the FETCH com- mand with a NO response that includes the "UNKNOWN-TRANSPORT-ENCOD- ING" extended response code. A client that receives such an extended response code can then retry the FETCH command without the BINARY extension and attempt to decode the data itself. The BINARY extension MUST only be used for terminal (leaf) MIME body parts. It MUST NOT be used to retrieve headers or composite MIME body parts. If a client uses the BINARY extension to request the transmission of a non-terminal MIME body part the server MUST reject the command with a NO response. Nerenberg draft-nerenberg-imap-binary-00.txt [Page 2]
Internet Draft IMAP4 Binary Content Extension November 2000 5. 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. 6. 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]. CHARALL ::= <0x00 - 0xff> literal8 ::= "{" number "}" CRLF *CHARALL ;; Number represents the number of CHARALL octets in ;; the response string. resp_code_text /= "UNKNOWN-TRANSPORT-ENCODING" section_text /= "BINARY" ;; BINARY is valid ONLY for terminal MIME body parts. 7. 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", RFC2119, March 1997 [MIME] Freed, N., N. Borenstein, "Multipurpose Internet Mail Exten- sions (MIME) Part One: Format of Internet Message Bodies", RFC2045, November 1996. 8. Security Considerations Sending binary data to clients that are expecting well-formed non-binary input is a common method used to attempt to bypass secu- rity. The IMAP4 BINARY extension is only initiated at a co-operat- ing client's request, therefore the transmission of binary content as defined in this memo does not affect legacy clients that may be unable to properly cope with such binary content. Nerenberg draft-nerenberg-imap-binary-00.txt [Page 3]
Internet Draft IMAP4 Binary Content Extension November 2000 9. 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-00.txt [Page 4]