rfc2061.txt
上传用户:ycwykj01
上传日期:2007-01-04
资源大小:1819k
文件大小:6k
源码类别:

网络编程

开发平台:

Unix_Linux

  1. Network Working Group                                         M. Crispin
  2. Request for Comments: 2061                      University of Washington
  3. Category: Informational                                    December 1996
  4.                    IMAP4 COMPATIBILITY WITH IMAP2BIS
  5. Status of this Memo
  6.    This memo provides information for the Internet community.  This memo
  7.    does not specify an Internet standard of any kind.  Distribution of
  8.    this memo is unlimited.
  9. Introduction
  10.    The Internet Message Access Protocol (IMAP) has been through several
  11.    revisions and variants in its 10-year history.  Many of these are
  12.    either extinct or extremely rare; in particular, several undocumented
  13.    variants and the variants described in RFC 1064, RFC 1176, and RFC
  14.    1203 fall into this category.
  15.    One variant, IMAP2bis, is at the time of this writing very common and
  16.    has been widely distributed with the Pine mailer.  Unfortunately,
  17.    there is no definite document describing IMAP2bis.  This document is
  18.    intended to be read along with RFC 1176 and the most recent IMAP4
  19.    specification (RFC 2060) to assist implementors in creating an IMAP4
  20.    implementation to interoperate with implementations that conform to
  21.    earlier specifications.  Nothing in this document is required by the
  22.    IMAP4 specification; implementors must decide for themselves whether
  23.    they want their implementation to fail if it encounters old software.
  24.    At the time of this writing, IMAP4 has been updated from the version
  25.    described in RFC 1730.  An implementor who wishes to interoperate
  26.    with both RFC 1730 and RFC 2060 should refer to both documents.
  27.    This information is not complete; it reflects current knowledge of
  28.    server and client implementations as well as "folklore" acquired in
  29.    the evolution of the protocol.  It is NOT a description of how to
  30.    interoperate with all variants of IMAP, but rather with the old
  31.    variant that is most likely to be encountered.  For detailed
  32.    information on interoperating with other old variants, refer to RFC
  33.    1732.
  34. IMAP4 client interoperability with IMAP2bis servers
  35.    A quick way to check whether a server implementation supports the
  36.    IMAP4 specification is to try the CAPABILITY command.  An OK response
  37.    will indicate which variant(s) of IMAP4 are supported by the server.
  38. Crispin                      Informational                      [Page 1]
  39. RFC 2061                  IMAP4 Compatibility              December 1996
  40.    If the client does not find any of its known variant in the response,
  41.    it should treat the server as IMAP2bis.  A BAD response indicates an
  42.    IMAP2bis or older server.
  43.    Most IMAP4 facilities are in IMAP2bis.  The following exceptions
  44.    exist:
  45.    CAPABILITY command
  46.             The absense of this command indicates IMAP2bis (or older).
  47.    AUTHENTICATE command.
  48.             Use the LOGIN command.
  49.    LSUB, SUBSCRIBE, and UNSUBSCRIBE commands
  50.             No direct functional equivalent.  IMAP2bis had a concept
  51.             called "bboards" which is not in IMAP4.  RFC 1176 supported
  52.             these with the BBOARD and FIND BBOARDS commands.  IMAP2bis
  53.             augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD,
  54.             and UNSUBSCRIBE BBOARD commands.  It is recommended that
  55.             none of these commands be implemented in new software,
  56.             including servers that support old clients.
  57.    LIST command
  58.             Use the command FIND ALL.MAILBOXES, which has a similar syn-
  59.             tax and response to the FIND MAILBOXES command described in
  60.             RFC 1176.  The FIND MAILBOXES command is unlikely to produce
  61.             useful information.
  62.    * in a sequence
  63.             Use the number of messages in the mailbox from the EXISTS
  64.             unsolicited response.
  65.    SEARCH extensions (character set, additional criteria)
  66.             Reformulate the search request using only the RFC 1176 syn-
  67.             tax.  This may entail doing multiple searches to achieve the
  68.             desired results.
  69.    BODYSTRUCTURE fetch data item
  70.             Use the non-extensible BODY data item.
  71.    body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
  72.             Use body section numbers only.
  73.    BODY.PEEK[section]
  74.             Use BODY[section] and manually clear the Seen flag as
  75.             necessary.
  76. Crispin                      Informational                      [Page 2]
  77. RFC 2061                  IMAP4 Compatibility              December 1996
  78.    FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
  79.             Use the corresponding non-SILENT versions and ignore the
  80.             untagged FETCH responses which come back.
  81.    UID fetch data item and the UID commands
  82.             No functional equivalent.
  83.    CLOSE command
  84.             No functional equivalent.
  85.    In IMAP2bis, the TRYCREATE special information token is sent as a
  86.    separate unsolicited OK response instead of inside the NO response.
  87.    IMAP2bis is ambiguous about whether or not flags or internal dates
  88.    are preserved on COPY.  It is impossible to know what behavior is
  89.    supported by the server.
  90. IMAP4 server interoperability with IMAP2bis clients
  91.    The only interoperability problem between an IMAP4 server and a
  92.    well-written IMAP2bis client is an incompatibility with the use of
  93.    "" in quoted strings.  This is best avoided by using literals
  94.    instead of quoted strings if "" or <"> is embedded in the string.
  95. Security Considerations
  96.    Security issues are not discussed in this memo.
  97. Author's Address
  98.    Mark R. Crispin
  99.    Networks and Distributed Computing
  100.    University of Washington
  101.    4545 15th Aveneue NE
  102.    Seattle, WA  98105-4527
  103.    Phone: (206) 543-5762
  104.    EMail: MRC@CAC.Washington.EDU
  105. Crispin                      Informational                      [Page 3]