rfc2061.txt
上传用户:ycwykj01
上传日期:2007-01-04
资源大小:1819k
文件大小:6k
- 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]