IMAP4 Literal+: IMAP4 non-synchronizing literals
Let an IMAP client send a string without pausing for the server's go-ahead.
Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, DOI 10.17487/RFC2088, January 1997, <https://www.rfc-editor.org/info/rfc2088>.
@misc{rfc2088,
series = {Request for Comments},
number = 2088,
howpublished = {RFC 2088},
publisher = {RFC Editor},
doi = {10.17487/RFC2088},
url = {https://www.rfc-editor.org/info/rfc2088},
author = {J. Myers},
title = {{IMAP4 non-synchronizing literals}},
pagetotal = 2,
year = 1997,
month = jan,
} RFC text
Contents
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
AI ELI5
On this page
§1The Round Trip Problem
The Internet Message Access Protocol (IMAP4) has a syntactic construct called a literal for sending strings. When a client sends one, IMAP4 requires it to wait for the server to send a command continuation request between the octet count and the string data.
This document defines an alternate form of literal that does not need this network round trip. The original form is then called a synchronizing literal.
Each time the client wants to send a long string, it has to stop and wait for a thumbs-up. That waiting is slow.
§3The Plus Sign Form
A non-synchronizing literal may be sent from client to server instead of the normal form. It is marked by a plus (+) between the octet count and the closing brace. The server does not send a continuation request for it, and the client need not wait before sending the octets.
A client may use it only with a server that lists LITERAL+ in its response to the CAPABILITY command. Otherwise the client must use synchronizing literals.
The server must check the end of every received line for an open brace, an octet count, a plus and a close brace right before the CRLF. When it finds that, it MUST treat the stated number of following octets and the next line as part of the same command. It MAY still process commands and reject errors line by line, as long as it checks each line end.
A little plus sign says "I am not waiting, here it comes". The client may only do this if the server said earlier that it understands the plus sign.
§4Example and Grammar
The RFC's example is a LOGIN command in which both the user name and the password are sent as non-synchronizing literals, with no server prompts in between.
The formal syntax, in augmented BNF, changes the literal rule so that the + is optional: an open brace, a number, an optional plus, a close brace, CRLF, then the octets. The RFC reports no known security issues with the extension.
In the example, the client sends a name and a password back to back, and the server just says the login worked.
C: A001 LOGIN {11+}
C: FRED FOOBAR {7+}
C: fat man
S: A001 OK LOGIN completed