[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 rfc2061                                                    
Network Working Group                                         M. Crispin
Internet Draft: IMAP4 Compatibility             University of Washington
Document: internet-drafts/draft-crispin-imap-compat-00.txt    March 1996


                   IMAP4 COMPATIBILITY WITH IMAP2BIS


Status of this Memo


   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   A revised version of this draft document will be submitted to the RFC
   editor as an Informational RFC for the Internet Community.
   Discussion and suggestions for improvement are requested, and should
   be sent to imap@CAC.Washington.EDU.  This document will expire before
   30 September 1996.  Distribution of this memo is unlimited.

   This document is based upon RFC 1732, but with a focus toward
   interoperability with IMAP2bis and not with other, extremely rare,
   variants of IMAP.



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



Crispin                                                         [Page 1]


INTERNET DRAFT           IMAP4 - Compatibility                March 1996


   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 (currently an Internet Draft) 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 is being updated from the version
   described in RFC 1730.  An implementor who wishes to interoperate
   with both RFC 1730 and the updated version 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.





























Crispin                                                         [Page 2]


INTERNET DRAFT           IMAP4 - Compatibility                March 1996


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.
   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.



Crispin                                                         [Page 3]


INTERNET DRAFT           IMAP4 - Compatibility                March 1996


   BODY.PEEK[section]
            Use BODY[section] and manually clear the \Seen flag as
            necessary.

   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.






























Crispin                                                         [Page 4]


INTERNET DRAFT           IMAP4 - Compatibility                March 1996


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                                                         [Page 5]