idnits 2.17.1 draft-crispin-imap-compat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1996) is 10267 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Crispin 3 Internet Draft: IMAP4 Compatibility University of Washington 4 Document: internet-drafts/draft-crispin-imap-compat-00.txt March 1996 6 IMAP4 COMPATIBILITY WITH IMAP2BIS 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 A revised version of this draft document will be submitted to the RFC 27 editor as an Informational RFC for the Internet Community. 28 Discussion and suggestions for improvement are requested, and should 29 be sent to imap@CAC.Washington.EDU. This document will expire before 30 30 September 1996. Distribution of this memo is unlimited. 32 This document is based upon RFC 1732, but with a focus toward 33 interoperability with IMAP2bis and not with other, extremely rare, 34 variants of IMAP. 36 Introduction 38 The Internet Message Access Protocol (IMAP) has been through several 39 revisions and variants in its 10-year history. Many of these are 40 either extinct or extremely rare; in particular, several undocumented 41 variants and the variants described in RFC 1064, RFC 1176, and RFC 42 1203 fall into this category. 44 One variant, IMAP2bis, is at the time of this writing very common and 45 has been widely distributed with the Pine mailer. Unfortunately, 46 there is no definite document describing IMAP2bis. This document is 47 intended to be read along with RFC 1176 and the most recent IMAP4 48 specification (currently an Internet Draft) to assist implementors in 49 creating an IMAP4 implementation to interoperate with implementations 50 that conform to earlier specifications. Nothing in this document is 51 required by the IMAP4 specification; implementors must decide for 52 themselves whether they want their implementation to fail if it 53 encounters old software. 55 At the time of this writing, IMAP4 is being updated from the version 56 described in RFC 1730. An implementor who wishes to interoperate 57 with both RFC 1730 and the updated version should refer to both 58 documents. 60 This information is not complete; it reflects current knowledge of 61 server and client implementations as well as "folklore" acquired in 62 the evolution of the protocol. It is NOT a description of how to 63 interoperate with all variants of IMAP, but rather with the old 64 variant that is most likely to be encountered. For detailed 65 information on interoperating with other old variants, refer to RFC 66 1732. 68 IMAP4 client interoperability with IMAP2bis servers 70 A quick way to check whether a server implementation supports the 71 IMAP4 specification is to try the CAPABILITY command. An OK response 72 will indicate which variant(s) of IMAP4 are supported by the server. 73 If the client does not find any of its known variant in the response, 74 it should treat the server as IMAP2bis. A BAD response indicates an 75 IMAP2bis or older server. 77 Most IMAP4 facilities are in IMAP2bis. The following exceptions 78 exist: 80 CAPABILITY command 81 The absense of this command indicates IMAP2bis (or older). 83 AUTHENTICATE command. 84 Use the LOGIN command. 86 LSUB, SUBSCRIBE, and UNSUBSCRIBE commands 87 No direct functional equivalent. IMAP2bis had a concept 88 called "bboards" which is not in IMAP4. RFC 1176 supported 89 these with the BBOARD and FIND BBOARDS commands. IMAP2bis 90 augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD, 91 and UNSUBSCRIBE BBOARD commands. It is recommended that 92 none of these commands be implemented in new software, 93 including servers that support old clients. 95 LIST command 96 Use the command FIND ALL.MAILBOXES, which has a similar syn- 97 tax and response to the FIND MAILBOXES command described in 98 RFC 1176. The FIND MAILBOXES command is unlikely to produce 99 useful information. 101 * in a sequence 102 Use the number of messages in the mailbox from the EXISTS 103 unsolicited response. 105 SEARCH extensions (character set, additional criteria) 106 Reformulate the search request using only the RFC 1176 syn- 107 tax. This may entail doing multiple searches to achieve the 108 desired results. 110 BODYSTRUCTURE fetch data item 111 Use the non-extensible BODY data item. 113 body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT 114 Use body section numbers only. 116 BODY.PEEK[section] 117 Use BODY[section] and manually clear the \Seen flag as 118 necessary. 120 FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items 121 Use the corresponding non-SILENT versions and ignore the 122 untagged FETCH responses which come back. 124 UID fetch data item and the UID commands 125 No functional equivalent. 127 CLOSE command 128 No functional equivalent. 130 In IMAP2bis, the TRYCREATE special information token is sent as a 131 separate unsolicited OK response instead of inside the NO response. 133 IMAP2bis is ambiguous about whether or not flags or internal dates 134 are preserved on COPY. It is impossible to know what behavior is 135 supported by the server. 137 IMAP4 server interoperability with IMAP2bis clients 139 The only interoperability problem between an IMAP4 server and a 140 well-written IMAP2bis client is an incompatibility with the use of 141 "\" in quoted strings. This is best avoided by using literals 142 instead of quoted strings if "\" or <"> is embedded in the string. 144 Security Considerations 146 Security issues are not discussed in this memo. 148 Author's Address: 150 Mark R. Crispin 151 Networks and Distributed Computing 152 University of Washington 153 4545 15th Aveneue NE 154 Seattle, WA 98105-4527 156 Phone: (206) 543-5762 158 EMail: MRC@CAC.Washington.EDU