imapext-2007

annotate docs/rfc/rfc3691.txt @ 0:ada5e610ab86

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

UW-IMAP'd extensions by yuuji