RFC 1203 (rfc1203) - Page 2 of 49
Interactive Mail Access Protocol: Version 3
Alternative Format: Original Text Document
RFC 1203 IMAP3 February 1991 - RFC 1176 pays only lip-service to being network protocol independent and, in fact assumes the use of TCP/IP. Neither RFC 1064 nor this proposal make any such assumption. Although there are numerous other detailed objections to RFC 1176, we believe that the above will serve to show that we believe strongly in the importance of mailbox abstraction level mail protocols and, after a couple of years of use of IMAP2 under RFC 1064 we believe that we have a good enough understanding of the issues involved to be able to take the next step. It is important to take this next step because of the rapid pace of both mail system and user interface development. We believe that, for IMAP not to die in its infancy, IMAP must be ready to respond to emerging ISO and RFC standards in mail, such as for multi-media mail. We believe that RFC 1176 not only provides a very small increment in functionality over RFC 1064 but also adds a number of bugs, which would be detrimental to the IMAP cause. Thus we propose the following definition for IMAP3. Compatibility notes: In revising the IMAP2 protocol it has been our intent, wherever possible to make upwards compatible changes to produce IMAP3. There were, however, some places that had to be changed incompatibly in order to compensate for either ambiguities in the IMAP2 protocol as defined by RFC 1064 or behavior that proved undesirable in the light of experience. It is our goal, however, that existing IMAP2 clients should still be supported and that, at least for the foreseeable future, all IMAP3 servers will support IMAP2 behavior as their default mode. The following are the major differences between this proposal, RFC 1176 and RFC 1064: - In this proposal we specify a difference between "solicited" and "unsolicited" data sent from the server. It is generally the case that data sent by the server can be sent either in response to an explicit request by the client or by the server of its own volition. Any data that the server is required to sent to the client as the result of a request is said to be solicited and carries the same tag as the request that provoked it. Any data sent by the server to the client that is not required by the protocol is said to be unsolicited and carries the special "*" tag. RFC 1176 preserves the original RFC 1064 terminology that calls all such data sent by the server "unsolicited" even when Rice
