1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc3691.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                                        A. Melnikov
    1.11 +Request for Comments: 3691                                    Isode Ltd.
    1.12 +Category: Standards Track                                  February 2004
    1.13 +
    1.14 +
    1.15 +        Internet Message Access Protocol (IMAP) UNSELECT command
    1.16 +
    1.17 +Status of this Memo
    1.18 +
    1.19 +   This document specifies an Internet standards track protocol for the
    1.20 +   Internet community, and requests discussion and suggestions for
    1.21 +   improvements.  Please refer to the current edition of the "Internet
    1.22 +   Official Protocol Standards" (STD 1) for the standardization state
    1.23 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.24 +
    1.25 +Copyright Notice
    1.26 +
    1.27 +   Copyright (C) The Internet Society (2004).  All Rights Reserved.
    1.28 +
    1.29 +Abstract
    1.30 +
    1.31 +   This document defines an UNSELECT command that can be used to close
    1.32 +   the current mailbox in an Internet Message Access Protocol - version
    1.33 +   4 (IMAP4) session without expunging it.  Certain types of IMAP
    1.34 +   clients need to release resources associated with the selected
    1.35 +   mailbox without selecting a different mailbox.  While IMAP4 provides
    1.36 +   this functionality (via a SELECT command with a nonexistent mailbox
    1.37 +   name or reselecting the same mailbox with EXAMINE command), a more
    1.38 +   clean solution is desirable.
    1.39 +
    1.40 +Table of Contents
    1.41 +
    1.42 +   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
    1.43 +   2.  UNSELECT command . . . . . . . . . . . . . . . . . . . . . . .  2
    1.44 +   3.  Security Considerations. . . . . . . . . . . . . . . . . . . .  3
    1.45 +   4.  Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . .  3
    1.46 +   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  3
    1.47 +   6.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  3
    1.48 +   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
    1.49 +   8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
    1.50 +   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  5
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Melnikov                    Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 3691                 IMAP UNSELECT command             February 2004
    1.64 +
    1.65 +
    1.66 +1.  Introduction
    1.67 +
    1.68 +   Certain types of IMAP clients need to release resources associated
    1.69 +   with the selected mailbox without selecting a different mailbox.
    1.70 +   While [IMAP4] provides this functionality (via a SELECT command with
    1.71 +   a nonexistent mailbox name or reselecting the same mailbox with
    1.72 +   EXAMINE command), a more clean solution is desirable.
    1.73 +
    1.74 +   [IMAP4] defines the CLOSE command that closes the selected mailbox as
    1.75 +   well as permanently removes all messages with the \Deleted flag set.
    1.76 +
    1.77 +   However [IMAP4] lacks a command that simply closes the mailbox
    1.78 +   without expunging it.  This document defines the UNSELECT command for
    1.79 +   this purpose.
    1.80 +
    1.81 +   A server which supports this extension indicates this with a
    1.82 +   capability name of "UNSELECT".
    1.83 +
    1.84 +   "C:" and "S:" in examples show lines sent by the client and server
    1.85 +   respectively.
    1.86 +
    1.87 +   The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
    1.88 +   this document when typed in uppercase are to be interpreted as
    1.89 +   defined in "Key words for use in RFCs to Indicate Requirement Levels"
    1.90 +   [KEYWORDS].
    1.91 +
    1.92 +2.  UNSELECT Command
    1.93 +
    1.94 +   Arguments:  none
    1.95 +
    1.96 +   Responses:  no specific responses for this command
    1.97 +
    1.98 +   Result:     OK - unselect completed, now in authenticated state
    1.99 +               BAD - no mailbox selected, or argument supplied but
   1.100 +                     none permitted
   1.101 +
   1.102 +      The UNSELECT command frees server's resources associated with the
   1.103 +      selected mailbox and returns the server to the authenticated
   1.104 +      state.  This command performs the same actions as CLOSE, except
   1.105 +      that no messages are permanently removed from the currently
   1.106 +      selected mailbox.
   1.107 +
   1.108 +   Example:    C: A341 UNSELECT
   1.109 +               S: A341 OK Unselect completed
   1.110 +
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Melnikov                    Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 3691                 IMAP UNSELECT command             February 2004
   1.120 +
   1.121 +
   1.122 +3.  Security Considerations
   1.123 +
   1.124 +   It is believed that this extension doesn't raise any additional
   1.125 +   security concerns not already discussed in [IMAP4].
   1.126 +
   1.127 +4.  Formal Syntax
   1.128 +
   1.129 +   The following syntax specification uses the Augmented Backus-Naur
   1.130 +   Form (ABNF) notation as specified in [ABNF].  Non-terminals
   1.131 +   referenced but not defined below are as defined by [IMAP4].
   1.132 +
   1.133 +   Except as noted otherwise, all alphabetic characters are case-
   1.134 +   insensitive.  The use of upper or lower case characters to define
   1.135 +   token strings is for editorial clarity only.  Implementations MUST
   1.136 +   accept these strings in a case-insensitive fashion.
   1.137 +
   1.138 +   command-select  /= "UNSELECT"
   1.139 +
   1.140 +5.  IANA Considerations
   1.141 +
   1.142 +   IMAP4 capabilities are registered by publishing a standards track or
   1.143 +   IESG approved experimental RFC.  The registry is currently located
   1.144 +   at:
   1.145 +
   1.146 +      http://www.iana.org/assignments/imap4-capabilities
   1.147 +
   1.148 +   This document defines the UNSELECT IMAP capabilities.  IANA has added
   1.149 +   this capability to the registry.
   1.150 +
   1.151 +6.  Acknowledgments
   1.152 +
   1.153 +   UNSELECT command was originally implemented by Tim Showalter in Cyrus
   1.154 +   IMAP server.
   1.155 +
   1.156 +   Also, the author of the document would like to thank Vladimir Butenko
   1.157 +   and Mark Crispin for reminding that UNSELECT has to be documented.
   1.158 +   Also thanks to Simon Josefsson for pointing out that there are
   1.159 +   multiple ways to implement UNSELECT.
   1.160 +
   1.161 +
   1.162 +
   1.163 +
   1.164 +
   1.165 +
   1.166 +
   1.167 +
   1.168 +
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Melnikov                    Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 3691                 IMAP UNSELECT command             February 2004
   1.176 +
   1.177 +
   1.178 +7.  Normative References
   1.179 +
   1.180 +   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   1.181 +              Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.182 +
   1.183 +   [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
   1.184 +              4rev1", RFC 3501, March 2003.
   1.185 +
   1.186 +   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
   1.187 +              Specifications: ABNF", RFC 2234, November 1997.
   1.188 +
   1.189 +8.  Author's Address
   1.190 +
   1.191 +   Alexey Melnikov
   1.192 +   Isode Limited
   1.193 +   5 Castle Business Village
   1.194 +   Hampton, Middlesex TW12 2BX
   1.195 +
   1.196 +   EMail: Alexey.Melnikov@isode.com
   1.197 +   URI: http://www.melnikov.ca/
   1.198 +
   1.199 +
   1.200 +
   1.201 +
   1.202 +
   1.203 +
   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 +Melnikov                    Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 3691                 IMAP UNSELECT command             February 2004
   1.232 +
   1.233 +
   1.234 +9.  Full Copyright Statement
   1.235 +
   1.236 +   Copyright (C) The Internet Society (2004).  This document is subject
   1.237 +   to the rights, licenses and restrictions contained in BCP 78 and
   1.238 +   except as set forth therein, the authors retain all their rights.
   1.239 +
   1.240 +   This document and the information contained herein are provided on an
   1.241 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   1.242 +   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   1.243 +   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   1.244 +   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   1.245 +   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.246 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.247 +
   1.248 +Intellectual Property
   1.249 +
   1.250 +   The IETF takes no position regarding the validity or scope of any
   1.251 +   Intellectual Property Rights or other rights that might be claimed
   1.252 +   to pertain to the implementation or use of the technology
   1.253 +   described in this document or the extent to which any license
   1.254 +   under such rights might or might not be available; nor does it
   1.255 +   represent that it has made any independent effort to identify any
   1.256 +   such rights.  Information on the procedures with respect to
   1.257 +   rights in RFC documents can be found in BCP 78 and BCP 79.
   1.258 +
   1.259 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.260 +   assurances of licenses to be made available, or the result of an
   1.261 +   attempt made to obtain a general license or permission for the use
   1.262 +   of such proprietary rights by implementers or users of this
   1.263 +   specification can be obtained from the IETF on-line IPR repository
   1.264 +   at http://www.ietf.org/ipr.
   1.265 +
   1.266 +   The IETF invites any interested party to bring to its attention
   1.267 +   any copyrights, patents or patent applications, or other
   1.268 +   proprietary rights that may cover technology that may be required
   1.269 +   to implement this standard.  Please address the information to the
   1.270 +   IETF at ietf-ipr@ietf.org.
   1.271 +
   1.272 +Acknowledgement
   1.273 +
   1.274 +   Funding for the RFC Editor function is currently provided by the
   1.275 +   Internet Society.
   1.276 +
   1.277 +
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Melnikov                    Standards Track                     [Page 5]
   1.286 +