Network Working Group L. Nerenberg Internet Draft: IMAP4 Binary Content Extension ACI Worldwide Document: draft-nerenberg-imap-binary-03.txt 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. 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 data without using a content-trans- fer-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]. The abbreviation CTE means content-transfer-encoding. In examples, "C:" and "S:" preface lines sent by the client and the server respectively. Nerenberg draft-nerenberg-imap-binary-03.txt [Page 1] Internet Draft IMAP4 Binary Content Extension May 2001 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 otherwise able to do so. The overhead of MIME encoding this content can be considerable in some contexts (e.g. slow radio links, streaming multimedia). Reduc- ing the overhead associated with CTE schemes such as base64 can give a noticeable reduction in resource consumption. The BINARY extension lets the server perform CTE decoding prior to transmit- ting message data to the client. 4. Content-Transfer-Encoding Considerations Every MIME message has a content-transfer-encoding. (Those without an explicit Content-Transfer-Encoding header are implicitly labeled as "7bit".) In the terminology of [MIME-IMB], the CTE specifies both a decoding algorithm and the domain of the decoded data. In the context of this memo, "decoding" refers to the CTE decoding step described in [MIME-IMB]. Certain CTEs use an identity encoding transformation. For these CTEs there is no decoding required, however the domain of the underlying data may not be expressable in the IMAP4 protocol (e.g. "8bit" with NUL octets). To accommodate these cases the BINARY extension introduces into the IMAP4 protocol a new type of literal element that is fully 8bit transparent. Thus, server processing of the FETCH BINARY command involves two logical steps: 1) perform any CTE-related decoding 2) determine the domain of the decoded data Step 2 is necessary to determine which protocol element should be used to transmit the decoded data. (See FETCH Response Extensions for further details.) 5. Framework for the IMAP4 Binary Extension This memo defines the following extensions to [IMAP4rev1]. 5.1. CAPABILITY Identification IMAP4 servers that support this extension MUST include "BINARY" in the response list to the CAPABILITY command. Nerenberg draft-nerenberg-imap-binary-03.txt [Page 2] Internet Draft IMAP4 Binary Content Extension May 2001 5.2. FETCH Command Extensions This extension defines three new FETCH command data items. BINARY[]<> Requests that the specified body section be transmitted after performing CTE-related decoding. When performing a partial FETCH, the offset argument refers to the offset into the ENCODED body section. BINARY.PEEK[]<> An alternate form of BINARY[
] that does not implic- itly set the \Seen flag. BINARY.SIZE[]<> Requests the decoded size of the body section (i.e. the size to expect in response to the corresponding FETCH BINARY request). When performing a partial FETCH, the offset argument refers to the offset into the ENCODED body section. Client authors are cautioned that this may be an expensive operation for some server implementations. Needlessly issuing this request could result in degraded performance due to servers having to calculate the value every time the request is issued. Requests that specify an offset will almost always require the server to calculate the result dynamically. 5.3. FETCH Response Extensions This extension defines two new FETCH response data items. BINARY[
]<> A or expressing the body content of the specified body section after removing any CTE-related encod- ing. If the domain of the decoded data is "8bit" and the data does not contain the NUL character, the server SHOULD return the data in a instead of a ; this allows the client to determine if the "8bit" data contains the NUL char- acter without having to explicitly scan the data stream for NULs. If the server does not know how to decode the body section's CTE, it MUST fail the request and issue a "NO" response with the "UNKNOWN-TRANSFER-ENCODING" extended response code. If the range of a partial FETCH does not refer to a valid sequence of octets for the the body section's CTE, the server MUST fail the request and issue a BAD response. Nerenberg draft-nerenberg-imap-binary-03.txt [Page 3] Internet Draft IMAP4 Binary Content Extension May 2001 BINARY.SIZE[
]<> The size of the section after removing any CTE-related encod- ing. The value returned MUST match the or size that will be returned by a corresponding FETCH BINARY request. If the server does not know how to decode the body section's CTE, it MUST fail the request and issue a "NO" response with the "UNKNOWN-TRANSFER-ENCODING" extended response code. If the range of a partial FETCH does not refer to a valid sequence of octets for the the body section's CTE, the server MUST fail the request and issue a BAD response. 5.4. APPEND Command Extensions The APPEND command is extended to allow the client to append data containing NULs by using the syntax. The server MAY mod- ify the CTE of the appended data, however any such transformation MUST NOT result in a loss of data. If the specified mailbox does not support the storage of binary content the server MUST reject the APPEND command with a NO response that includes the "UNKNOWN-TRANSFER-ENCODING" extended response code. 6. Interoperability Considerations Messaging clients and servers have been notoriously lax in their adherence to the Internet CRLF convention for terminating lines of textual data in Internet protocols. When sending data using the BINARY extension, servers MUST ensure that textual line-oriented body sections are always transmitted using the IMAP4 CRLF line ter- mination syntax, regardless of the underlying storage representa- tion of the data on the server. While the server is allowed to modify the CTE of APPENDed data, this should only be done where absolutely necessary. Gratuitous encoding changes will render useless most cryptographic operations that may have been performed on the message. This extension provides an optimization that is useful in certain specific situations. 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. Nerenberg draft-nerenberg-imap-binary-03.txt [Page 4] Internet Draft IMAP4 Binary Content Extension May 2001 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]. append =/ "APPEND" SPACE mailbox [SPACE flag_list] [SPACE date_time] SPACE literal8 BINCHAR ::= <0x00 - 0xff> fetch_att =/ "BINARY" [ (".PEEK" / "SIZE") ] section_binary ["<" number "." nz_number ">"] / literal8 ::= "~{" number "}" CRLF *BINCHAR ;; represents the number of BINCHAR octets ;; in the response string. resp_code_text =/ "UNKNOWN-TRANSFER-ENCODING" section_binary ::= "[" [ (nz_number *["." nz_number] ] "]" 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 There are no known security issues with this extension. Nerenberg draft-nerenberg-imap-binary-03.txt [Page 5] Internet Draft IMAP4 Binary Content Extension May 2001 10. Authors' Address Lyndon Nerenberg ACI Worldwide Suite 900 10117 - Jasper Avenue Edmonton, Alberta Canada T5J 1W8 Email: lyndon@messagingdirect.com Nerenberg draft-nerenberg-imap-binary-03.txt [Page 6]