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: 2000-Sep-13
Document File: 20 page(s) / 53K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Leiba: AUTHOR

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 5% 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.

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

implem...