Summary

  • RFC 1176 made some IMAP2 commands optional. For FIND MAILBOXES and FIND BBOARDS, a BAD reply left the client unable to tell why the attempt had failed.
  • RFC 1203 called itself a counterproposal and specified SUPPORTED.VERSIONS, SELECT.VERSION and SELECT.FEATURES so the client could discover and select the behavior available on a server.

In the 1990 IMAP2 revision, a client could try to list mailboxes and receive BAD. The document said support for FIND MAILBOXES was optional; when the attempt returned BAD, the client could make no assumptions. A menu button built around that command was a wager. The server knew its own abilities. The workstation had to knock on doors to find out.

John Rice's RFC 1203, published in February 1991, did not politely call this a minor improvement opportunity. It described itself as a counterproposal to RFC 1176 and alleged that the earlier revision had been made without internal consultation with the IMAP community. That is Rice's account of the process. The technical complaint can be checked directly against the two documents: RFC 1176 offered optional behavior but no feature list a client could request before building its interface around it.

IMAP3 put three commands on the table. SUPPORTED.VERSIONS asked the server which protocol versions and features it supported. SELECT.VERSION chose a version. SELECT.FEATURES enabled or disabled named features. The worked exchange in RFC 1203 first asks for the list, then selects version 3.0 and the TAGGED.SOLICITED feature. The order matters. Discovery precedes commitment; an unsupported selection receives NO. A client can decide which controls to show before a user presses one.

The proposal also kept the old door open. A connection began with IMAP2 behavior under RFC 1064; the server would not switch behavior until the client selected a version or features. Rice wanted existing IMAP2 clients to remain usable. This was a fight over how change should be announced, rather than a demand that every workstation upgrade at once. RFC 1203 even required version selection before choosing a mailbox because a server might need a different program to serve a different protocol version; state might not survive that switch.

There was another dispute hidden in the client. RFC 1176's appendix told an IMAP2 client to maintain a local cache, an incomplete model of the mailbox, and described how replies updated it. RFC 1203 objected to the server making assumptions about the client's caching architecture. If a protocol dictates the shape of private client state, one implementation's convenience can become every other client's obligation. Rice also proposed a clearer separation between replies required by a command, bearing that command's tag, and server-initiated data bearing *. Multiple searches could then be in flight while a server worked through slow storage.

RFC 1203 was Experimental for the Internet community and is now marked Historic in the RFC Editor's record. It supplies no census of deployment or verdict on whose code prevailed. Its historical value lies in the visible argument: a specification can make a command optional, but a usable interface needs a way to discover the option. In 1991, one side wrote that uncertainty into the client; the other published a protocol for asking the server.

Sources