RFC 3516

IMAP4 Binary Content Extension

📅 published April 2003, from ietf

RFC 3516: IMAP4 Binary Content Extension ✨

okay bestie, this RFC is RFC 3516 🦋, titled "IMAP4 Binary Content Extension." It was written by Lyndon Nerenberg of Orthanc Systems in April 2003 💅. It's on the Standards Track 👑. The header doesn't list anything it obsoletes or updates, so there's nothing to report there 🌸.

Status of this Memo

this is an Internet standards track protocol for the Internet community 🫶 and it's asking for discussion and suggestions for improvements 💬. for where it sits in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📜. distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒✨

Abstract

this memo defines the Binary extension to IMAP4 (the Internet Message Access Protocol) 📬. it gives clients and servers a way to swap 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 read as described in [KEYWORD] 💖. these are the capital-letter rules, so pay attention to them 👀.

"CTE" is short for content-transfer-encoding 🍓.

2. Introduction 🧚

okay so MIME lets you send non-text (binary) message content [MIME-IMB] 🎀. the thing is, the traditional messaging transports can't always pass binary data straight through 😭. MIME fixes that with encoding schemes that let binary content ride over transports that otherwise couldn't carry it 💅.

the catch? MIME encoding can be a LOT of overhead in some situations, like slow radio links or streaming multimedia 🐢. cutting down the overhead of CTE schemes such as base64 can noticeably save resources ✨. the Binary extension lets the server do the CTE decoding before it sends message data to the client 🚀. iconic, honestly 👑.

3. Content-Transfer-Encoding Considerations 💜

every IMAP4 body section has a MIME content-transfer-encoding 🧁. if a section has no explicit Content-Transfer-Encoding header, it's 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" means the CTE decoding step described in [MIME-IMB] 🦋.

some CTEs use an identity encoding transformation. for those, there's no decoding needed 😌. BUT the domain of the underlying data might not be expressible in the IMAP4 protocol, like MIME "binary" content with NUL octets 💀. so to handle these cases, the Binary extension brings in a new kind of literal protocol element that is fully eight bit transparent 🔥.

so server processing of the FETCH BINARY command has two logical steps 🎀:

  1. perform any CTE-related decoding
  2. determine the domain of the decoded data

step 2 matters because it decides which protocol element gets used to transmit the decoded data 🧚. (see FETCH Response Extensions for the 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 🎀. no skipping this one, bestie 🙅‍♀️.

4.2. FETCH Command Extensions 🌸

this extension defines three new FETCH command data items 🍓:

BINARY<section-binary>[<partial>]

requests that the specified section be sent after CTE-related decoding 🫶.

the <partial> argument, if it's there, asks for just a subset of the data 🧩. partial FETCH BINARY works the same as partial FETCH BODY, with one twist: 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 (basically, the size to expect back from the matching FETCH BINARY request) 📏.

Note: client authors are cautioned that this might be an expensive operation for some server implementations 💀. needlessly issuing this request could tank performance, because servers would have to calculate the value every single time it's requested 😭.

4.3. FETCH Response Extensions 📦

this extension defines two new FETCH response data items 💖:

BINARY<section-binary>[<<number>>]

this is an <nstring> or <literal8> holding the content of the specified section after any CTE-related encoding has been removed ✨. if <number> is present, it's the offset within the DECODED section data 🧩.

if the domain of the decoded data is "8bit" and the data doesn't contain the NUL octet, the server SHOULD return the data in a <string> instead of a <literal8> 🎀. the reason is slay: the client can tell whether the "8bit" data has a NUL octet without having to scan the whole data stream for NULs 🔍✨.

if the server doesn't know how to decode the section's CTE, it MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code 💀.

BINARY.SIZE<section-binary>

the size of the section after any CTE-related encoding has been removed 📏. the value returned MUST match the size of the <nstring> or <literal8> that the corresponding FETCH BINARY request will return 🫶.

if the server doesn't know how to decode the section's CTE, it MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code 🙈.

4.4. APPEND Command Extensions 📨

the APPEND command gets extended so the client can append data containing NULs using the <literal8> syntax 🎀. the server MAY modify the CTE of the appended data 🦋, but any such transformation MUST NOT result in a loss of data 🛡️.

if the destination mailbox doesn't support storing binary content, the server MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code 💀.

5. MIME Encoded Headers 💌

[MIME-MHE] defines an encoding that allows non-US-ASCII text in message headers 🌍. this encoding is not the same as the content-transfer-encoding used on message bodies 🙅‍♀️. so the decoding transformations in this memo do NOT apply to [MIME-MHE] encoded header text 🎀.

a server MUST NOT perform any conversion of [MIME-MHE] encoded header text in response to any binary FETCH or APPEND request 🛑.

6. Implementation Considerations 🛠️

okay real talk, messaging clients and servers have been notoriously lax about the Internet CRLF convention for ending lines of textual data 😭. when sending data with the Binary extension, servers MUST make sure textual line-oriented sections are always sent using the IMAP4 CRLF line termination syntax 🎀, no matter how the data is stored on the server 💅.

a server may choose to store message body binary content in a non-encoded format 🧁. but whatever the internal storage looks like, the server MUST issue BODYSTRUCTURE responses that describe the message as if the binary-encoded sections were encoded in a CTE the IMAP4 base specification accepts 🫶. and the results of a FETCH BODY MUST return the message body content in the format described by the matching FETCH BODYSTRUCTURE response 🔍.

the server is allowed to modify the CTE of APPENDed <literal8> data, but it should only do that when it's absolutely necessary 🙈. gratuitous encoding changes will wreck most cryptographic operations already performed on the message 💀🔐.

this extension is an optimization for certain specific situations 🦋. it does NOT let clients skip basic functionality (content transfer decoding) that every messaging client should have 💅. clients supporting this extension SHOULD be prepared to do their own CTE decoding operations 🌈✨.

Okay bestie, this is the legal bit, so I'm keeping the wording exactly as it is 💅 Copyright is the one thing you can't remix, so here it is in full 🎀

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶

📦 where this page comes from