IMAP4 Binary Content Extension
RFC 3516
Document | Type |
RFC - Proposed Standard
(April 2003; Errata)
Updated by RFC 4466
Was draft-nerenberg-imap-binary (individual in app area)
|
|
---|---|---|---|
Author | Lyndon Nerenberg | ||
Last updated | 2020-01-21 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3516 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ned Freed | ||
IESG note | ApprovedĀ 14-Nov-2002 | ||
Send notices to | (None) |
Network Working Group L. Nerenberg Request for Comments: 3516 Orthanc Systems Category: Standards Track April 2003 IMAP4 Binary Content Extension Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content- transfer-encoding. 1. 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. 2. Introduction The MIME extensions to Internet messaging allow for the transmission 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). Reducing the overhead associated with CTE schemes such as base64 Nerenberg Standards Track [Page 1] RFC 3516 IMAP4 Binary Content Extension April 2003 can give a noticeable reduction in resource consumption. The Binary extension lets the server perform CTE decoding prior to transmitting message data to the client. 3. Content-Transfer-Encoding Considerations Every IMAP4 body section has a MIME content-transfer-encoding. (Those without an explicit Content-Transfer-Encoding header are implicitly labeled as "7bit" content.) In the terminology of [MIME- IMB], the CTE specifies both a decoding algorithm and the domain of the decoded data. In 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 expressible in the IMAP4 protocol (e.g., MIME "binary" content containing NUL octets). To accommodate these cases the Binary extension introduces a new type of literal protocol element that is fully eight bit 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.) 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 three new FETCH command data items. BINARY<section-binary>[<partial>] Requests that the specified section be transmitted after performing CTE-related decoding. Nerenberg Standards Track [Page 2] RFC 3516 IMAP4 Binary Content Extension April 2003 The <partial> argument, if present, requests that a subset of the data be returned. The semantics of a partial FETCH BINARY command are the same as for a partial FETCH BODY command, with the exception that the <partial> arguments refer to the DECODED section data. BINARY.PEEK<section-binary>[<partial>] An alternate form of FETCH BINARY that does not implicitly set the \Seen flag. BINARY.SIZE<section-binary> Requests the decoded size of the section (i.e., the size to expect in response to the corresponding FETCH BINARY request). Note: client authors are cautioned that this might 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. 4.3. FETCH Response Extensions This extension defines two new FETCH response data items.Show full document text