Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

IMAP4 Binary Content Extension (RFC3516)

IP.com Disclosure Number: IPCOM000012212D
Original Publication Date: 2003-Apr-01
Included in the Prior Art Database: 2003-Apr-17
Document File: 9 page(s) / 15K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

L. Nerenberg: AUTHOR

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 19% of the total text.

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" conten...