RFC 2088

Title block 🎀

IMAP4 non-synchronizing literals 💖

Network Working Group, Request for Comments: 2088 🦋

Author: J. Myers of Carnegie Mellon 🌸

Category: Standards Track 🔥

Date: January 1997 📅

This doc doesn't list anything it obsoletes or updates, so it's standing on its own ✨

---

Status of This Memo 📜

okay so this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅

---

1. Abstract ✨

IMAP4 (the Internet Message Access Protocol) has this "literal" construct for sending strings around 🧚 When a client sends a literal to a server, IMAP4 makes the client wait for the server to send a command continuation request between the octet count and the actual string data. Ugh, the round trip 😭 This doc defines a different form of literal that skips that round trip entirely. Iconic 👑

---

2. Conventions Used in this Document 🍓

In the examples, "C:" means lines the client sends and "S:" means lines the server sends. Simple! 💜

---

3. Specification 🌈

So the non-synchronizing literal is an alternate form of literal. It can show up in client-to-server communication in place of the IMAP4 form, which is called a synchronizing literal ⭐

Non-synchronizing literals may be used with any IMAP4 server that returns "LITERAL+" as one of its supported capabilities in response to the CAPABILITY command 🦋 If the server doesn't advertise the LITERAL+ capability, the client must use synchronizing literals instead 🙈

How do you tell them apart? A non-synchronizing literal has a plus (+) between the octet count and the closing brace (}) 💖 The server does not generate a command continuation request for a non-synchronizing literal, and clients are not required to wait before sending the octets of one. Main character energy 💅

Now the server side, which is lowkey the important bit 🔥 The protocol receiver of an IMAP4 server must check the end of every received line. It's looking for an open brace ({), then an octet count, then a plus (+), then a close brace (}), all sitting right before the CRLF. If it finds that, the number is the octet count of a non-synchronizing literal, and the server MUST treat that many following octets and the rest of 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. Flexible, no cap 🫶

Here's an example:

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

Look at that, the whole thing is one command 🎀

---

4. Formal Syntax 💜

This syntax uses the augmented Backus-Naur Form (BNF) notation from [RFC-822], as modified by [IMAP4]. Anything referenced here but not defined below is 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. Lowkey scary-quiet, but the spec says what it says, so take it seriously 🫶

---

8. Author's Address 🌸

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

Email: jgm+@cmu.edu 💌