1 files changed, 171 insertions, 0 deletions
diff --git a/RFC/rfc2061.txt b/RFC/rfc2061.txt
new file mode 100644
index 00000000..7cb02bb2
--- /dev/null
+++ b/RFC/rfc2061.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+