1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc1732.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,283 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                         M. Crispin
    1.11 +Request for Comments: 1732                      University of Washington
    1.12 +Category: Informational                                    December 1994
    1.13 +
    1.14 +
    1.15 +              IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
    1.16 +
    1.17 +
    1.18 +Status of this Memo
    1.19 +
    1.20 +   This memo provides information for the Internet community.  This memo
    1.21 +   does not specify an Internet standard of any kind.  Distribution of
    1.22 +   this memo is unlimited.
    1.23 +
    1.24 +Introduction
    1.25 +
    1.26 +   This is a summary of hints and recommendations to enable an IMAP4
    1.27 +   implementation to interoperate with implementations that conform to
    1.28 +   earlier specifications.  None of these hints and recommendations are
    1.29 +   required by the IMAP4 specification; implementors must decide for
    1.30 +   themselves whether they want their implementation to fail if it
    1.31 +   encounters old software.
    1.32 +
    1.33 +   IMAP4 has been designed to be upwards compatible with earlier
    1.34 +   specifications.  For the most part, IMAP4 facilities that were not in
    1.35 +   earlier specifications should be invisible to clients unless the
    1.36 +   client asks for the facility.
    1.37 +
    1.38 +   In some cases, older servers may support some of the capabilities
    1.39 +   listed as being "new in IMAP4" as experimental extensions to the
    1.40 +   IMAP2 protocol described in RFC 1176.
    1.41 +
    1.42 +   This information may not be complete; it reflects current knowledge
    1.43 +   of server and client implementations as well as "folklore" acquired
    1.44 +   in the evolution of the protocol.
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Crispin                                                         [Page 1]
    1.62 +
    1.63 +RFC 1732                 IMAP4 - Compatibility             December 1994
    1.64 +
    1.65 +
    1.66 +IMAP4 client interoperability with old servers
    1.67 +
    1.68 +   In general, a client should be able to discover whether an IMAP2
    1.69 +   server supports a facility by trial-and-error; if an attempt to use a
    1.70 +   facility generates a BAD response, the client can assume that the
    1.71 +   server does not support the facility.
    1.72 +
    1.73 +   A quick way to check whether a server implementation supports the
    1.74 +   IMAP4 specification is to try the CAPABILITY command.  An OK response
    1.75 +   that includes the IMAP4 capability value indicates a server that
    1.76 +   supports IMAP4; a BAD response or one without the IMAP4 capability
    1.77 +   value indicates an older server.
    1.78 +
    1.79 +   The following is a list of facilities that are only in IMAP4, and
    1.80 +   suggestions for how new clients might interoperate with old servers:
    1.81 +
    1.82 +   CAPABILITY command
    1.83 +            A BAD response to this command indicates that the server
    1.84 +            implements IMAP2 (or IMAP2bis) and not IMAP4.
    1.85 +
    1.86 +   AUTHENTICATE command.
    1.87 +            Use the LOGIN command.
    1.88 +
    1.89 +   LSUB and LIST commands
    1.90 +            Try the RFC 1176 FIND command.
    1.91 +
    1.92 +   * in a sequence
    1.93 +            Use the number of messages in the mailbox from the EXISTS
    1.94 +            unsolicited response.
    1.95 +
    1.96 +   SEARCH extensions (character set, additional criteria)
    1.97 +            Reformulate the search request using only the searching
    1.98 +            options listed in search_old in the IMAP4 grammar.  This may
    1.99 +            entail doing multiple searches to achieve the desired
   1.100 +            results.
   1.101 +
   1.102 +   BODYSTRUCTURE fetch data item
   1.103 +            Try to fetch the non-extensible BODY data item.
   1.104 +
   1.105 +   body section number 0
   1.106 +            Fetch the entire message and extract the header.
   1.107 +
   1.108 +   RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
   1.109 +            Use RFC822.HEADER and remove the unwanted information.
   1.110 +
   1.111 +   BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
   1.112 +            items Use the corresponding non-PEEK versions and manually
   1.113 +            clear the \Seen flag as necessary.
   1.114 +
   1.115 +
   1.116 +
   1.117 +Crispin                                                         [Page 2]
   1.118 +
   1.119 +RFC 1732                 IMAP4 - Compatibility             December 1994
   1.120 +
   1.121 +
   1.122 +   UID fetch data item and the UID commands
   1.123 +            No equivalent capabilitity exists in older servers.
   1.124 +
   1.125 +   FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
   1.126 +            Use the corresponding non-SILENT versions and ignore the
   1.127 +            untagged FETCH responses which com eback.
   1.128 +
   1.129 +
   1.130 +   The following IMAP4 facilities were introduced in the experimental
   1.131 +   IMAP2bis revisions to RFC-1176, and may be present in a server that
   1.132 +   does not support the CAPABILITY command:
   1.133 +
   1.134 +   CREATE, DELETE, and RENAME commands
   1.135 +            To test whether these commands are present, try a CREATE
   1.136 +            INBOX command.  If the response is NO, these commands are
   1.137 +            supported by the server.  If the response is BAD, they are
   1.138 +            not.  Older servers without the CREATE capability may sup-
   1.139 +            port implicit creation of a mailbox by a COPY command with a
   1.140 +            non-existant name as the destination.
   1.141 +
   1.142 +   APPEND command
   1.143 +            To test whether this command is present, try to append a
   1.144 +            zero-length stream to a mailbox name that is known not to
   1.145 +            exist (or at least, highly unlikely to exist) on the remote
   1.146 +            system.
   1.147 +
   1.148 +   SUBSCRIBE and UNSUBSCRIBE commands
   1.149 +            Try the form of these commands with the optional MAILBOX
   1.150 +            keyword.
   1.151 +
   1.152 +   EXAMINE command
   1.153 +            Use the SELECT command instead.
   1.154 +
   1.155 +   flags and internal date argument to APPEND command
   1.156 +            Try the APPEND without any flag list and internal date argu-
   1.157 +            ments.
   1.158 +
   1.159 +   BODY, BODY[section], and FULL fetch data items
   1.160 +            Use RFC822.TEXT and ALL instead.  Server does not support
   1.161 +            MIME.
   1.162 +
   1.163 +   PARTIAL command
   1.164 +            Use the appropriate FETCH command and ignore the unwanted
   1.165 +            data.
   1.166 +
   1.167 +
   1.168 +   IMAP4 client implementations must accept all responses and data for-
   1.169 +   mats documented in the IMAP4 specification, including those labeled
   1.170 +
   1.171 +
   1.172 +
   1.173 +Crispin                                                         [Page 3]
   1.174 +
   1.175 +RFC 1732                 IMAP4 - Compatibility             December 1994
   1.176 +
   1.177 +
   1.178 +   as obsolete.  This includes the COPY and STORE unsolicited responses
   1.179 +   and the old format of dates and times.  In particular, client imple-
   1.180 +   mentations must not treat a date/time as a fixed format string; nor
   1.181 +   may they assume that the time begins at a particular octet.
   1.182 +
   1.183 +   IMAP4 client implementations must not depend upon the presence of any
   1.184 +   server extensions that are not in the base IMAP4 specification.
   1.185 +
   1.186 +   The experimental IMAP2bis version specified that the TRYCREATE spe-
   1.187 +   cial information token is sent as a separate unsolicited OK response
   1.188 +   instead of inside the NO response.
   1.189 +
   1.190 +   The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
   1.191 +   are removed from IMAP4.  There is no equivalent to the bboard com-
   1.192 +   mands, which provided a separate namespace with implicit restrictions
   1.193 +   on what may be done in that namespace.
   1.194 +
   1.195 +   Older server implementations may automatically create the destination
   1.196 +   mailbox on COPY if that mailbox does not already exist.  This was how
   1.197 +   a new mailbox was created in older specifications.  If the server
   1.198 +   does not support the CREATE command (see above for how to test for
   1.199 +   this), it will probably create a mailbox on COPY.
   1.200 +
   1.201 +   Older server implementations may not preserve flags or internal dates
   1.202 +   on COPY.  Some server implementations may not permit the preservation
   1.203 +   of certain flags on COPY or their setting with APPEND as site policy.
   1.204 +
   1.205 +
   1.206 +
   1.207 +
   1.208 +
   1.209 +
   1.210 +
   1.211 +
   1.212 +
   1.213 +
   1.214 +
   1.215 +
   1.216 +
   1.217 +
   1.218 +
   1.219 +
   1.220 +
   1.221 +
   1.222 +
   1.223 +
   1.224 +
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Crispin                                                         [Page 4]
   1.230 +
   1.231 +RFC 1732                 IMAP4 - Compatibility             December 1994
   1.232 +
   1.233 +
   1.234 +IMAP4 server interoperability with old clients
   1.235 +
   1.236 +   In general, there should be no interoperation problem between a
   1.237 +   server conforming to the IMAP4 specification and a well-written
   1.238 +   client that conforms to an earlier specification.  Known problems are
   1.239 +   noted below:
   1.240 +
   1.241 +      Poor wording in the description of the CHECK command in earlier
   1.242 +      specifications implied that a CHECK command is the way to get the
   1.243 +      current number of messages in the mailbox.  This is incorrect.  A
   1.244 +      CHECK command does not necessarily result in an EXISTS response.
   1.245 +      Clients must remember the most recent EXISTS value sent from the
   1.246 +      server, and should not generate unnecessary CHECK commands.
   1.247 +
   1.248 +      An incompatibility exists with COPY in IMAP4.  COPY in IMAP4
   1.249 +      servers does not automatically create the destination mailbox if
   1.250 +      that mailbox does not already exist.  This may cause problems with
   1.251 +      old clients that expect automatic mailbox creation in COPY.
   1.252 +
   1.253 +      The PREAUTH unsolicited response is new in IMAP4.  It is highly
   1.254 +      unlikely that an old client would ever see this response.
   1.255 +
   1.256 +      The format of dates and times has changed due to the impending end
   1.257 +      of the century.  Clients that fail to accept a four-digit year or
   1.258 +      a signed four-digit timezone value will not work properly with
   1.259 +      IMAP4.
   1.260 +
   1.261 +      An incompatibility exists with the use of "\" in quoted strings.
   1.262 +      This is best avoided by using literals instead of quoted strings
   1.263 +      if "\" or <"> is embedded in the string.
   1.264 +
   1.265 +Security Considerations
   1.266 +
   1.267 +   Security issues are not discussed in this memo.
   1.268 +
   1.269 +Author's Address:
   1.270 +
   1.271 +   Mark R. Crispin
   1.272 +   Networks and Distributed Computing, JE-30
   1.273 +   University of Washington
   1.274 +   Seattle, WA  98195
   1.275 +
   1.276 +   Phone: (206) 543-5762
   1.277 +
   1.278 +   EMail: MRC@CAC.Washington.EDU
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Crispin                                                         [Page 5]
   1.286 +