summaryrefslogtreecommitdiff
path: root/imap/docs/rfc/rfc2061.txt
diff options
context:
space:
mode:
Diffstat (limited to 'imap/docs/rfc/rfc2061.txt')
-rw-r--r--imap/docs/rfc/rfc2061.txt171
1 files changed, 0 insertions, 171 deletions
diff --git a/imap/docs/rfc/rfc2061.txt b/imap/docs/rfc/rfc2061.txt
deleted file mode 100644
index 7cb02bb2..00000000
--- a/imap/docs/rfc/rfc2061.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-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 RFC 1064, RFC 1176, 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 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; 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.
-
-
-
-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. 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. 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 syn-
- tax 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 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.
-
-
-
-
-
-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]
-