diff options
Diffstat (limited to 'imap/docs/rfc/rfc2061.txt')
| -rw-r--r-- | imap/docs/rfc/rfc2061.txt | 171 |
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] - |