RFC 2088 PROPOSED STANDARD EMAIL · IMAP

IMAP4 Literal+: IMAP4 non-synchronizing literals

An IMAP literal form that lets a client send data without waiting for a continuation request.

On rfc-editor.org ↗
PUBLISHED
January 1997
AUTHORS
J. Myers
STREAM
Legacy
OBSOLETED BY
RFC 7888 — IMAP LITERAL+
UPDATED BY
RFC 4466 — IMAP ABNF extensions
DOI
10.17487/RFC2088

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                           J. Myers
Request for Comments: 2088                               Carnegie Mellon
Cateogry: Standards Track                                   January 1997


                    IMAP4 non-synchronizing literals

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.

1.   Abstract

   The Internet Message Access Protocol [IMAP4] contains the "literal"
   syntactic construct for communicating strings.  When sending a
   literal from client to server, IMAP4 requires the client to wait for
   the server to send a command continuation request between sending the
   octet count and the string data.  This document specifies an
   alternate form of literal which does not require this network round
   trip.

2.   Conventions Used in this Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

3.   Specification

   The non-synchronizing literal is added an alternate form of literal,
   and may appear in communication from client to server instead of the
   IMAP4 form of literal.  The IMAP4 form of literal, used in
   communication from client to server, is referred to as a
   synchronizing literal.

   Non-synchronizing literals may be used with any IMAP4 server
   implementation which returns "LITERAL+" as one of the supported
   capabilities to the CAPABILITY command.  If the server does not
   advertise the LITERAL+ capability, the client must use synchronizing
   literals instead.

   The non-synchronizing literal is distinguished from the original
   synchronizing literal by having a plus ('+') between the octet count
   and the closing brace ('}').  The server does not generate a command
   continuation request in response to a non-synchronizing literal, and
   clients are not required to wait before sending the octets of a non-
   synchronizing literal.

   The protocol receiver of an IMAP4 server must check the end of every
   received line for an open brace ('{') followed by an octet count, a
   plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
   If it finds this sequence, it is the octet count of a non-
   synchronizing literal and the server MUST treat the specified number
   of following octets and the following line as part of the same
   command.  A server MAY still process commands and reject errors on a
   line-by-line basis, as long as it checks for non-synchronizing
   literals at the end of each line.

   Example:    C: A001 LOGIN {11+}
               C: FRED FOOBAR {7+}
               C: fat man
               S: A001 OK LOGIN completed

4.   Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
   Non-terminals referenced but not defined below are as defined by
   [IMAP4].

   literal         ::= "{" number ["+"] "}" CRLF *CHAR8
                       ;; Number represents the number of CHAR8 octets

6.   References

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
   draft-crispin-imap-base-XX.txt, University of Washington, April 1996.

   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822.

7.   Security Considerations

   There are no known security issues with this extension.

8.   Author's Address

   John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave.
   Pittsburgh PA, 15213-3890

   Email: jgm+@cmu.edu

ISO Plain Language

On this page
PROBLEMWith a synchronizing IMAP literal, the client waits for the server's continuation request after sending the octet count and before sending the string.
MECHANISMA non-synchronizing literal adds a plus sign before the closing brace. The client can send its data immediately when the server advertises the LITERAL+ capability.
STATUS TODAYRFC 2088 was obsoleted by RFC 7888 and updated by RFC 4466.

§1The Extra Round Trip

IMAP4 uses literals to communicate strings. In the normal client-to-server form, the client sends the octet count and waits for a command continuation request before sending the string data.

RFC 2088 defines an alternative that avoids this wait. It calls the original form a synchronizing literal and the new form a non-synchronizing literal.

The usual literal form makes the client pause for the server's signal before sending the string. This extension allows the client to continue without that pause.

§3The Plus-Sign Form

A non-synchronizing literal is marked with a plus sign between the octet count and closing brace, as in {11+}. The server does not send a continuation request, and the client does not need to wait before sending the stated number of octets.

A client may use the form only if the server advertises LITERAL+ in its CAPABILITY response. Otherwise, it must use synchronizing literals. The server must detect the marker at the end of a line and treat the specified following octets and line as part of the same command.

The plus sign tells the server that the literal data follows right away. The client first checks that the server announced LITERAL+ support.

§4Example and Formal Syntax

The RFC shows a LOGIN command in which the client sends literals for the user name and password without waiting for continuation requests between them. The server then returns a tagged successful completion.

The formal syntax allows an optional plus sign inside the literal marker. The RFC reports no known security issues with the extension.

The example sends both login strings consecutively. A server that supports the extension does not ask for a separate go-ahead between them.