--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Crispin
+Request for Comments: 2061 University of Washington
+Category: Informational December 1996
+
+
+ IMAP4 COMPATIBILITY WITH IMAP2BIS
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Introduction
+
+ The Internet Message Access Protocol (IMAP) has been through several
+ revisions and variants in its 10-year history. Many of these are
+ either extinct or extremely rare; in particular, several undocumented
+ variants and the variants described in RFC 1064, RFC 1176, and RFC
+ 1203 fall into this category.
+
+ One variant, IMAP2bis, is at the time of this writing very common and
+ has been widely distributed with the Pine mailer. Unfortunately,
+ there is no definite document describing IMAP2bis. This document is
+ intended to be read along with RFC 1176 and the most recent IMAP4
+ specification (RFC 2060) to assist implementors in creating an IMAP4
+ implementation to interoperate with implementations that conform to
+ earlier specifications. Nothing in this document is required by the
+ IMAP4 specification; implementors must decide for themselves whether
+ they want their implementation to fail if it encounters old software.
+
+ At the time of this writing, IMAP4 has been updated from the version
+ described in RFC 1730. An implementor who wishes to interoperate
+ with both RFC 1730 and RFC 2060 should refer to both documents.
+
+ This information is not complete; it reflects current knowledge of
+ server and client implementations as well as "folklore" acquired in
+ the evolution of the protocol. It is NOT a description of how to
+ interoperate with all variants of IMAP, but rather with the old
+ variant that is most likely to be encountered. For detailed
+ information on interoperating with other old variants, refer to RFC
+ 1732.
+
+IMAP4 client interoperability with IMAP2bis servers
+
+ A quick way to check whether a server implementation supports the
+ IMAP4 specification is to try the CAPABILITY command. An OK response
+ will indicate which variant(s) of IMAP4 are supported by the server.
+
+
+
+Crispin Informational [Page 1]
+\f
+RFC 2061 IMAP4 Compatibility December 1996
+
+
+ If the client does not find any of its known variant in the response,
+ it should treat the server as IMAP2bis. A BAD response indicates an
+ IMAP2bis or older server.
+
+ Most IMAP4 facilities are in IMAP2bis. The following exceptions
+ exist:
+
+ CAPABILITY command
+ The absense of this command indicates IMAP2bis (or older).
+
+ AUTHENTICATE command.
+ Use the LOGIN command.
+
+ LSUB, SUBSCRIBE, and UNSUBSCRIBE commands
+ No direct functional equivalent. IMAP2bis had a concept
+ called "bboards" which is not in IMAP4. RFC 1176 supported
+ these with the BBOARD and FIND BBOARDS commands. IMAP2bis
+ augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD,
+ and UNSUBSCRIBE BBOARD commands. It is recommended that
+ none of these commands be implemented in new software,
+ including servers that support old clients.
+
+ LIST command
+ Use the command FIND ALL.MAILBOXES, which has a similar syn-
+ tax and response to the FIND MAILBOXES command described in
+ RFC 1176. The FIND MAILBOXES command is unlikely to produce
+ useful information.
+
+ * in a sequence
+ Use the number of messages in the mailbox from the EXISTS
+ unsolicited response.
+
+ SEARCH extensions (character set, additional criteria)
+ Reformulate the search request using only the RFC 1176 syn-
+ tax. This may entail doing multiple searches to achieve the
+ desired results.
+
+ BODYSTRUCTURE fetch data item
+ Use the non-extensible BODY data item.
+
+ body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
+ Use body section numbers only.
+
+ BODY.PEEK[section]
+ Use BODY[section] and manually clear the \Seen flag as
+ necessary.
+
+
+
+
+
+Crispin Informational [Page 2]
+\f
+RFC 2061 IMAP4 Compatibility December 1996
+
+
+ FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
+ Use the corresponding non-SILENT versions and ignore the
+ untagged FETCH responses which come back.
+
+ UID fetch data item and the UID commands
+ No functional equivalent.
+
+ CLOSE command
+ No functional equivalent.
+
+
+ In IMAP2bis, the TRYCREATE special information token is sent as a
+ separate unsolicited OK response instead of inside the NO response.
+
+ IMAP2bis is ambiguous about whether or not flags or internal dates
+ are preserved on COPY. It is impossible to know what behavior is
+ supported by the server.
+
+IMAP4 server interoperability with IMAP2bis clients
+
+ The only interoperability problem between an IMAP4 server and a
+ well-written IMAP2bis client is an incompatibility with the use of
+ "\" in quoted strings. This is best avoided by using literals
+ instead of quoted strings if "\" or <"> is embedded in the string.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ Mark R. Crispin
+ Networks and Distributed Computing
+ University of Washington
+ 4545 15th Aveneue NE
+ Seattle, WA 98105-4527
+
+ Phone: (206) 543-5762
+ EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Informational [Page 3]
+\f
projects / uw-imap / commitdiff