Browse Prior Art Database

IMAP4 Implementation Recommendations (RFC2683)

IP.com Disclosure Number: IPCOM000003275D
Original Publication Date: 1999-Sep-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 23 page(s) / 35K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Leiba: AUTHOR

Related Documents

10.17487/RFC2683: DOI

Abstract

The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community.

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

Network Working Group B. Leiba Request for Comments: 2683 IBM T.J. Watson Research Center Category: Informational September 1999

IMAP4 Implementation Recommendations

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Abstract

The IMAP4 specification [RFC-2060] describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible.

2. Conventions used in this document

In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.

The words "must", "must not", "should", "should not", and "may" are used with specific meaning in this document; since their meaning is somewhat different from that specified in RFC 2119, we do not put them in all caps here. Their meaning is as follows:

must -- This word means that the action described is necessary to ensure interoperability. The recommendation should not be ignored. must not -- This phrase means that the action described will be almost certain to hurt interoperability. The recommendation should not be ignored.

Leiba Informational [Page 1]

RFC 2683 IMAP4 Implementation Recommendations September 1999

should -- This word means that the action described is strongly recommended and will enhance interoperability or usability. The recommendation should not be ignored without careful consideration. should not -- This phrase means that the action described is strongly recommended against, and might hurt interoperability or usability. The recommendation should not be ignored without careful consideration. may -- This word means that the action described is an acceptable implementation choice. No specific recommendation is implied; this word is used to point out a choice that might not be obvious, or to let implementors know what choices have been made by existing implementations.

3. Interoperability Issues and Recommendations

3.1. Accessibility

This section describes the issues related to access to servers and server resources. Concerns here include data sharing and maintenance of client/server connections.

3.1.1. Multiple Accesses of the Same Mailbox

One strong point of IMAP4 is that, unlike POP3, it allows for multiple simultaneous access to a single mailbox. A user can, thus, read mail from a client at home while the client in the office is still connected; or the help desk staff can all work out of the same inbox, all seeing the same pool of questions....

Processing...
Loading...