Browse Prior Art Database

IMAP4 Compatibility with IMAP2 and IMAP2bis (RFC1732)

IP.com Disclosure Number: IPCOM000003981D
Original Publication Date: 1994-Dec-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 5 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Crispin: AUTHOR

Related Documents

10.17487/RFC1732: DOI

Abstract

This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 38% of the total text.

Network Working Group M. Crispin Request for Comments: 1732 University of Washington Category: Informational December 1994

IMAP4 COMPATIBILITY WITH IMAP2 AND 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

This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. None of these hints and recommendations are required by the IMAP4 specification; implementors must decide for themselves whether they want their implementation to fail if it encounters old software.

IMAP4 has been designed to be upwards compatible with earlier specifications. For the most part, IMAP4 facilities that were not in earlier specifications should be invisible to clients unless the client asks for the facility.

In some cases, older servers may support some of the capabilities listed as being "new in IMAP4" as experimental extensions to the IMAP2 protocol described in RFC 1176.

This information may not be complete; it reflects current knowledge of server and client implementations as well as "folklore" acquired in the evolution of the protocol.

Crispin [Page 1]

RFC 1732 IMAP4 - Compatibility December 1994

IMAP4 client interoperability with old servers

In general, a client should be able to discover whether an IMAP2 server supports a facility by trial-and-error; if an attempt to use a facility generates a BAD response, the client can assume that the server does not support the facility.

A quick way to check whether a server implementation supports the IMAP4 specification is to try the CAPABILITY command. An OK response that includes the IMAP4 capability value indicates a server that supports IMAP4; a BAD response or one without the IMAP4 capability value indicates an older server.

The following is a list of facilities that are only in IMAP4, and suggestions for how new clients might interoperate with old servers:

CAPABILITY command A BAD response to this command indicates that the server implements IMAP2 (or IMAP2bis) and not IMAP4.

AUTHENTICATE command. Use the LOGIN command.

LSUB and LIST commands Try the RFC 1176 FIND command.

* 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 searching options listed in search_old in the IMAP4 grammar. This may entail doing multiple searches to achieve the desired results.

BODYSTRUCTURE fetch data item Try to fetch the non-extensible BODY data item.

body section number 0 Fetch the entire message and extract the header.

RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items Use RFC822.HEADER and remove the unwanted information.

BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data items Use the corresponding non-PEEK versions...

Processing...
Loading...