imap/docs/rfc/rfc3691.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        A. Melnikov
   8 Request for Comments: 3691                                    Isode Ltd.
   9 Category: Standards Track                                  February 2004
  10
  11
  12         Internet Message Access Protocol (IMAP) UNSELECT command
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (2004).  All Rights Reserved.
  25
  26 Abstract
  27
  28    This document defines an UNSELECT command that can be used to close
  29    the current mailbox in an Internet Message Access Protocol - version
  30    4 (IMAP4) session without expunging it.  Certain types of IMAP
  31    clients need to release resources associated with the selected
  32    mailbox without selecting a different mailbox.  While IMAP4 provides
  33    this functionality (via a SELECT command with a nonexistent mailbox
  34    name or reselecting the same mailbox with EXAMINE command), a more
  35    clean solution is desirable.
  36
  37 Table of Contents
  38
  39    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  40    2.  UNSELECT command . . . . . . . . . . . . . . . . . . . . . . .  2
  41    3.  Security Considerations. . . . . . . . . . . . . . . . . . . .  3
  42    4.  Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . .  3
  43    5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  3
  44    6.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  3
  45    7.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
  46    8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
  47    9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  5
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Melnikov                    Standards Track                     [Page 1]
  59 \f
  60 RFC 3691                 IMAP UNSELECT command             February 2004
  61
  62
  63 1.  Introduction
  64
  65    Certain types of IMAP clients need to release resources associated
  66    with the selected mailbox without selecting a different mailbox.
  67    While [IMAP4] provides this functionality (via a SELECT command with
  68    a nonexistent mailbox name or reselecting the same mailbox with
  69    EXAMINE command), a more clean solution is desirable.
  70
  71    [IMAP4] defines the CLOSE command that closes the selected mailbox as
  72    well as permanently removes all messages with the \Deleted flag set.
  73
  74    However [IMAP4] lacks a command that simply closes the mailbox
  75    without expunging it.  This document defines the UNSELECT command for
  76    this purpose.
  77
  78    A server which supports this extension indicates this with a
  79    capability name of "UNSELECT".
  80
  81    "C:" and "S:" in examples show lines sent by the client and server
  82    respectively.
  83
  84    The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
  85    this document when typed in uppercase are to be interpreted as
  86    defined in "Key words for use in RFCs to Indicate Requirement Levels"
  87    [KEYWORDS].
  88
  89 2.  UNSELECT Command
  90
  91    Arguments:  none
  92
  93    Responses:  no specific responses for this command
  94
  95    Result:     OK - unselect completed, now in authenticated state
  96                BAD - no mailbox selected, or argument supplied but
  97                      none permitted
  98
  99       The UNSELECT command frees server's resources associated with the
 100       selected mailbox and returns the server to the authenticated
 101       state.  This command performs the same actions as CLOSE, except
 102       that no messages are permanently removed from the currently
 103       selected mailbox.
 104
 105    Example:    C: A341 UNSELECT
 106                S: A341 OK Unselect completed
 107
 108
 109
 110
 111
 112
 113
 114 Melnikov                    Standards Track                     [Page 2]
 115 \f
 116 RFC 3691                 IMAP UNSELECT command             February 2004
 117
 118
 119 3.  Security Considerations
 120
 121    It is believed that this extension doesn't raise any additional
 122    security concerns not already discussed in [IMAP4].
 123
 124 4.  Formal Syntax
 125
 126    The following syntax specification uses the Augmented Backus-Naur
 127    Form (ABNF) notation as specified in [ABNF].  Non-terminals
 128    referenced but not defined below are as defined by [IMAP4].
 129
 130    Except as noted otherwise, all alphabetic characters are case-
 131    insensitive.  The use of upper or lower case characters to define
 132    token strings is for editorial clarity only.  Implementations MUST
 133    accept these strings in a case-insensitive fashion.
 134
 135    command-select  /= "UNSELECT"
 136
 137 5.  IANA Considerations
 138
 139    IMAP4 capabilities are registered by publishing a standards track or
 140    IESG approved experimental RFC.  The registry is currently located
 141    at:
 142
 143       http://www.iana.org/assignments/imap4-capabilities
 144
 145    This document defines the UNSELECT IMAP capabilities.  IANA has added
 146    this capability to the registry.
 147
 148 6.  Acknowledgments
 149
 150    UNSELECT command was originally implemented by Tim Showalter in Cyrus
 151    IMAP server.
 152
 153    Also, the author of the document would like to thank Vladimir Butenko
 154    and Mark Crispin for reminding that UNSELECT has to be documented.
 155    Also thanks to Simon Josefsson for pointing out that there are
 156    multiple ways to implement UNSELECT.
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Melnikov                    Standards Track                     [Page 3]
 171 \f
 172 RFC 3691                 IMAP UNSELECT command             February 2004
 173
 174
 175 7.  Normative References
 176
 177    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
 178               Requirement Levels", BCP 14, RFC 2119, March 1997.
 179
 180    [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
 181               4rev1", RFC 3501, March 2003.
 182
 183    [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
 184               Specifications: ABNF", RFC 2234, November 1997.
 185
 186 8.  Author's Address
 187
 188    Alexey Melnikov
 189    Isode Limited
 190    5 Castle Business Village
 191    Hampton, Middlesex TW12 2BX
 192
 193    EMail: Alexey.Melnikov@isode.com
 194    URI: http://www.melnikov.ca/
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Melnikov                    Standards Track                     [Page 4]
 227 \f
 228 RFC 3691                 IMAP UNSELECT command             February 2004
 229
 230
 231 9.  Full Copyright Statement
 232
 233    Copyright (C) The Internet Society (2004).  This document is subject
 234    to the rights, licenses and restrictions contained in BCP 78 and
 235    except as set forth therein, the authors retain all their rights.
 236
 237    This document and the information contained herein are provided on an
 238    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 239    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 240    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 241    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 242    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 243    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 244
 245 Intellectual Property
 246
 247    The IETF takes no position regarding the validity or scope of any
 248    Intellectual Property Rights or other rights that might be claimed
 249    to pertain to the implementation or use of the technology
 250    described in this document or the extent to which any license
 251    under such rights might or might not be available; nor does it
 252    represent that it has made any independent effort to identify any
 253    such rights.  Information on the procedures with respect to
 254    rights in RFC documents can be found in BCP 78 and BCP 79.
 255
 256    Copies of IPR disclosures made to the IETF Secretariat and any
 257    assurances of licenses to be made available, or the result of an
 258    attempt made to obtain a general license or permission for the use
 259    of such proprietary rights by implementers or users of this
 260    specification can be obtained from the IETF on-line IPR repository
 261    at http://www.ietf.org/ipr.
 262
 263    The IETF invites any interested party to bring to its attention
 264    any copyrights, patents or patent applications, or other
 265    proprietary rights that may cover technology that may be required
 266    to implement this standard.  Please address the information to the
 267    IETF at ietf-ipr@ietf.org.
 268
 269 Acknowledgement
 270
 271    Funding for the RFC Editor function is currently provided by the
 272    Internet Society.
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Melnikov                    Standards Track                     [Page 5]
 283 \f