RFC2061 - IMAP4 Compatibility with IMAP2bis

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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 RFC1064, RFC1176, 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 RFC1176 and the most recent IMAP4

specification (RFC2060) 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 RFC1730. An implementor who wishes to interoperate

with both RFC1730 and RFC2060 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.

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

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

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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航