WDIFF

draft-nerenberg-imap-binary-02.txt --> draft-nerenberg-imap-binary-03.txt

Network Working Group L. Nerenberg
Internet Draft: IMAP4 Binary Content Extension ACI/MessagingDirect ACI Worldwide
Document: draft-nerenberg-imap-binary-02.txt February 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.rq
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

Changes from version -01

Defined the use of <literal8> syntax to APPEND binary data.

Added BINARYSTRUCTURE.

Removed the restriction for terminal body sections only.

Added missing ']' in section 4.2 definitions of BINARY and
BINARY.PEEK.

Clarified when to return [UNKNOWN-TRANSFER-ENCODING] reponse.

Nerenberg draft-nerenberg-imap-binary-02.txt [Page 1]

Internet Draft IMAP4 Binary Content Extension February 2001

Changes from version -00

Renamed CHARALL to BINCHAR.

Changed syntax to "FETCH x BINARY ..."

Defined FETCH BINARY response.

Modified <literal8> syntax to distinguish it from <literal>.

Added examples section.

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 encoded with the MIME BINARY
content-transfer-encoding. 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. clients
connected over slow radio links). 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 extends lets the IMAP4 protocol server perform CTE decoding prior to allow clients 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 servers the domain of the decoded data. In
the context of this memo, "decoding" refers to exchange 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 binary (unencoded) format.

4. 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].

4.1.

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-02.txt draft-nerenberg-imap-binary-03.txt [Page 2]

Internet Draft IMAP4 Binary Content Extension February May 2001

4.2.

5.2. FETCH Command Extensions

This extension defines three new FETCH command data items.

BINARY[<section_binary>]<<partial>>
The binary content of a particular body section. This data
item acts as the [IMAP4rev1] BODY data item does, but with the
following modifications:

The server converts the MIME content-transfer-encoding of
Requests that the specified body section to BINARY before transmitting it to the client.
This content conversion MUST NOT cause a loss of information.
If the server cannot convert the content-transfer-encoding to
BINARY it MUST reject the FETCH command with a NO response
that includes the "UNKNOWN-TRANSFER-ENCODING" extended
response code. be transmitted after
performing CTE-related decoding.

When performing a partial FETCH, the offset argument refers to
the offset into the CONVERTED ENCODED body section.

BINARY.PEEK[<section_binary>]<<partial>>
An alternate form of BINARY[<section>] that does not implic-
itly set the \Seen flag.

BINARYSTRUCTURE
The MIME body structure

BINARY.SIZE[<section_binary>]<<partial>>
Requests the decoded size of the message after converting all body sections section (i.e. the size
to expect in response to the corresponding FETCH BINARY content-transfer-encoding. The
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 computes implementations. Needlessly issuing
this by parsing request could result in degraded performance due to
servers having to calculate the MIME structure of value every time the mes-
sage after performing any required content-transfer-encoding
modifications.

4.3. 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[<section>]<<origin_octet>>

BINARY[<section>]<<partial>>
A <string> or <literal8> expressing the body content of the
specified body section after converting the content-transfer-encoding to
BINARY. removing any CTE-related encod-
ing.

If the origin octet is specified, this string is a substring domain of the entire body contents, starting at that origin octet.
This means that BODY[]<0> MAY be truncated, but BODY[] decoded data is
NEVER truncated. The offset refers to the body contents after
conversion to the BINARY content-transfer-encoding.

BINARYSTRUCTURE
A parenthesized list describing the MIME body structure of the
message after converting all the sections to the BINARY con-
tent-transfer-encoding. The contents "8bit" and format of the list
are identical to those of the [IMAP4rev1] BODYSTRUCTURE
response, but describe the converted body.

Calculating the sizes of the converted content may impose

Nerenberg draft-nerenberg-imap-binary-02.txt [Page 3]

Internet Draft IMAP4 Binary Content Extension February 2001

considerable overhead on some implementations. A server MAY
choose to defer this calculation until the client fetches the
item. In this case, all size-related fields where the size of data does
not contain the converted content is unknown MUST be set to NIL. If NUL character, the server reports a non-NIL value for the message size it MUST
match the size of SHOULD return the <literal8>
data in a corresponding FETCH
BINARY response. For a complex message the server might defer
the size calculations for only a subset <literal> instead of the sections. In a <literal8>; this case allows the server SHOULD report
client to determine if the sizes for those sec-
tions where they can be easily determined. For example, given
a message with a 7BIT-encoded section and a BASE64-encoded
section, "8bit" data contains the server should return NUL char-
acter without having to explicitly scan the size data stream for the 7BIT-
encoded section, since the 7BIT- and BINARY-encoded sizes will
be the same.
NULs.

If the server is unable does not know how to convert decode the content-transfer-encod-
ing of a section to BINARY, body section's
CTE, it MUST report fail the corresponding
content encoding and message size fields as NIL, and SHOULD
report any other size-related fields as NIL. A section report-
ing NIL for content encoding request and message size cannot be
retrieved using FETCH BINARY, and servers MUST reject such
requests with issue a NO "NO" response that includes with
the "UNKNOWN-TRANS-
FER-ENCODING" "UNKNOWN-TRANSFER-ENCODING" extended response code.

Reporting a message encoding

If the range of NIL with a non-NIL message
size is a protocol error; servers MUST NOT return this combi-
nation of values.

4.4. APPEND Command Extensions

The APPEND command is extended to allow the client partial FETCH does not refer to append binary
data by specifying the octet count using <literal8> syntax. The
server SHOULD NOT perform any content-transfer-encoding conversion a valid
sequence of octets for the data.

If the specified mailbox does not support the storage of binary
content body section's CTE, the server
MUST reject fail the APPEND command with a NO
response that includes the "UNKNOWN-TRANSFER-ENCODING" extended
response code.

5. Examples

The examples in this section are illustrative only; they DO NOT
form part of this specification.

Most of these examples uses a message containing two sections: a
text/plain request and an application/octet-stream.

MIME Content MIME Encoded Unencoded
Part# Type Encoding Size Size
----------------------------------------------------------------
1 text/plain 7bit 105 105
2 application/octet-stream base64 3324344 2429327 issue a BAD response.

Nerenberg draft-nerenberg-imap-binary-02.txt draft-nerenberg-imap-binary-03.txt [Page 4] 3]

Internet Draft IMAP4 Binary Content Extension February May 2001

First,

BINARY.SIZE[<section>]<<origin_octet>>
The size of the client requests section after removing any CTE-related encod-
ing. The value returned MUST match the BODYSTRUCTURE:

C: 42 fetch 6 bodystructure
S: * 6 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii")
"<1070.981005923.1@localhost>" NIL "7BIT" 105 2 NIL NIL NIL)
("APPLICATION" "OCTET-STREAM" NIL "<1070.981005923.2@localhost>"
"The latest BSD kernel" "BASE64" 3324344 NIL NIL NIL) "MIXED"
("BOUNDARY" "----- =_aaaaaaaaaa0") NIL NIL))
S: 42 OK <literal> or <lit-
eral8> size that will be returned by a corresponding FETCH completed

Next
BINARY request.

If the client asks for server does not know how to decode the BINARYSTRUCTURE:

C: 43 fetch 6 binarystructure
S: * 6 FETCH (BINARYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii")
"<1070.981005923.1@localhost>" NIL "BINARY" 105 2 NIL NIL NIL)
("APPLICATION" "OCTET-STREAM" NIL "<1070.981005923.2@localhost>"
"The latest BSD kernel" "BINARY" 2429327 NIL NIL NIL) "MIXED"
("BOUNDARY" "----- =_aaaaaaaaaa0") NIL NIL))
S: 43 OK FETCH completed

Notice that body section's
CTE, it MUST fail the content transfer encoding for both sections has
changed to BINARY. The size for request and issue a "NO" response with
the "UNKNOWN-TRANSFER-ENCODING" extended response code.

If the second section has changed range of a partial FETCH does not refer to
reflect the conversion a valid
sequence of the BASE64 encoding octets for that section; the
size of the first section (both message size and line count) has
not changed, since body section's CTE, the transformation from 7BIT to BINARY did not
result in any change to server
MUST fail the data.

For sections with transparent content transfer encodings (7BIT,
8BIT, BINARY), FETCH BODY request and FETCH BINARY return identical con-
tent:

C: 3 fetch 1 body[1]
S: * 1 FETCH (BODY[1] {80}
S: This is issue a test message BAD response.

5.4. APPEND Command Extensions

The APPEND command is extended to use in allow the examples section client to append data
containing NULs by using the <literal8> syntax. The server MAY mod-
ify the CTE of the
S: IMAP BINARY RFC.
S: )
S: 3 OK Completed
C: 4 fetch 1 binary[1]
S: * 1 FETCH (BINARY[1] ~{80}
S: This is a test message to use appended data, however any such transformation
MUST NOT result in a loss of data.

If the examples section specified mailbox does not support the storage of binary
content the
S: IMAP BINARY RFC.
S: )
S: 4 OK Completed

Nerenberg draft-nerenberg-imap-binary-02.txt [Page 5]

Internet Draft IMAP4 Binary Content Extension February 2001

Here is a misbehaving client trying to retrieve server MUST reject the APPEND command with a body NO
response that includes the server
cannot decode:

C: 1 fetch 13 bodystructure
S: * 13 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" ("CHARSET"
"iso-8859-1") NIL NIL "FROBOZZ" 1716 49 NIL NIL NIL))
S: 1 OK Completed
C: 2 fetch 13 binarystructure
S: * 13 FETCH (BINARYSTRUCTURE ("TEXT" "PLAIN" ("CHARSET"
"iso-8859-1") NIL NIL NIL NIL NIL NIL NIL NIL))
S: 2 OK Completed
C: 3 fetch 13 binary[1]
S: 2 BAD [UNKNOWN-TRANSFER-ENCODING] Unknown content encoding
(FROBOZZ) for message 13 section 1 "UNKNOWN-TRANSFER-ENCODING" extended
response code.

6. Interoperability Considerations

Messaging clients and servers have been notoriously lax in their
adherance
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 <lit-
eral8> 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"] [ (".PEEK" / "SIZE") ] section_binary
["<" number "." nz_number ">"] /
"BINARYSTRUCTURE"

Nerenberg draft-nerenberg-imap-binary-02.txt [Page 6]

Internet Draft IMAP4 Binary Content Extension February 2001

literal8 ::= "~{" number "}" CRLF *BINCHAR
;; <number> 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

Sending binary data to servers and clients that

There are expecting well-
formed non-binary input is a method commonly used to attempt to
bypass security. The IMAP4 BINARY extension is only initiated at a
co-operating client's request, therefore the transmission of binary
content as defined in this memo should not affect legacy clients
that may be unable to properly cope no known security issues with such binary content. A new
protocol syntax has been introduced to further distinguish between
<literal> and <literal8> data. 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/MessagingDirect
ACI Worldwide
Suite 900
10117 - Jasper Avenue
Edmonton, Alberta
Canada T5J 1W8

Email: lyndon@messagingdirect.com

Nerenberg draft-nerenberg-imap-binary-02.txt draft-nerenberg-imap-binary-03.txt [Page 7] 6]

----