Summary

  • RFC 2062 removed obsolete IMAP forms from the main protocol while preserving a bounded map for implementations that still met older peers.
  • New servers were not required to accept obsolete commands and were generally forbidden to emit obsolete responses; clients could retain narrowly defined receive behavior.
  • Compatibility therefore described what a receiver might tolerate, not a continuing right for senders to generate the retired language.

The cleanest migration rarely happens on both sides of a connection at once. One party upgrades first. Another arrives months later. A parser may need to recognize yesterday's grammar even after the product has stopped choosing that grammar for any new conversation. RFC 2062 captured this imbalance in eight short pages.

The memo did not invent a new version of IMAP. It was Informational and said plainly that it specified no Internet standard. Its job was archival and operational: collect forms inherited from RFC 1176, experimental IMAP2bis practice and RFC 1730 after IMAP4rev1 moved on. That separation mattered. Old syntax remained documented without occupying the center of the current protocol.

The command list showed what retirement meant in practice. FIND ALL.MAILBOXES and FIND MAILBOXES had given older clients a way to enumerate names. SUBSCRIBE MAILBOX and UNSUBSCRIBE MAILBOX carried an extra keyword. PARTIAL asked for a range of one message item. Older FETCH names included BODY[0], RFC822.HEADER.LINES and several PEEK forms. RFC 2062 said new servers were not required to support these commands or data items. An implementor could choose to do so for an old client, but compatibility was optional service, not the protocol's new production language.

PARTIAL also exposes why replacing syntax can improve evidence. Its response did not identify the returned range. Multiple commands might execute out of order, so a client could not safely stream requests and concatenate results without processing each step. Modern partial FETCH syntax carried a clearer offset relationship. Functional resemblance did not make the two receipts equivalent.

The response rules were sharper still. Obsolete responses generally must not be transmitted by new servers. The old MAILBOX response survived only as the answer to obsolete FIND commands. An obsolete per-message COPY response had to be ignored by clients. An obsolete STORE response had to be treated as FETCH. “Accept the old response” therefore meant three different things: conditionally parse it, discard it, or normalize it into a current semantic form.

That is not permission to keep sending the past. RFC 2683 later warned clients not to infer validity from tolerance: some IMAP4rev1 servers happened to accept obsolete commands, but that did not make those commands proper to send. RFC 2061 made the broader policy explicit. Compatibility advice was not a base requirement; implementors had to decide how much old software they intended to meet, and some retired namespaces were better left unimplemented even on a compatibility server.

The protocol continued to use this directional discipline. RFC 3501 kept RFC 2062 as historical context. RFC 9051 later made revision choice visible through capabilities and ENABLE IMAP4rev2. A server advertising both revisions normally does not emit removed response forms unless an IMAP4rev1 client has requested the corresponding behavior. This is later evidence of the same engineering pattern, not proof that one memo caused the other.

For operators, the evidentiary lesson is simple. A successful parser test proves that a component can receive a form. It does not prove that the component is configured to generate it. A server accepting FIND proves neither that clients should send FIND nor that its response will use the old MAILBOX form outside that exchange. A capability token proves a declared mode, not the precise bytes that crossed a connection.

Safe retirement needs four separate records: accepted input grammar, configured output grammar, peer-negotiated mode and observed wire output. Collapse them into a single “supports legacy” flag and optional tolerance becomes permanent production authority. Keep them separate and compatibility can shrink deliberately: stop emission first, measure remaining reception, isolate exceptional peers, and remove the parser only when the evidence says the old estate is gone.

Sources