Mercurial > hgrepos > hgweb.cgi > imapext
comparison docs/rfc/rfc3691.txt @ 0:ada5e610ab86
imap-2007e
author | yuuji@gentei.org |
---|---|
date | Mon, 14 Sep 2009 15:17:45 +0900 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:ada5e610ab86 |
---|---|
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 | |
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 | |
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 | |
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 | |
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 |