Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc2061.txt.pdf Дата изменения: Wed Mar 27 23:21:56 2002 Дата индексирования: Tue Oct 2 18:53:34 2012 Кодировка:

Network Working Group Request for Comments: 2061 Category: Informational

M. Crispin University of Washington 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 revisions and variants in its 10-year history. either extinct or extremely rare; in particular, variants and the variants described in RFC 1064, 1203 fall into this category. been through several Many of these are several undocumented RFC 1176, and RFC

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; server and client implementations the evolution of the protocol. It interoperate with all variants of variant that is most likely to be information on interoperating with 1732. it reflects current knowledge of as well as "folklore" acquired in is NOT a description of how to IMAP, but rather with the old encountered. For detailed other old variants, refer to RFC

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. exist: The following exceptions

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