mirror of
https://github.com/uw-imap/imap.git
synced 2024-11-16 10:28:23 +01:00
284 lines
8.2 KiB
Plaintext
284 lines
8.2 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group A. Melnikov
|
||
Request for Comments: 3691 Isode Ltd.
|
||
Category: Standards Track February 2004
|
||
|
||
|
||
Internet Message Access Protocol (IMAP) UNSELECT command
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
This document defines an UNSELECT command that can be used to close
|
||
the current mailbox in an Internet Message Access Protocol - version
|
||
4 (IMAP4) session without expunging it. Certain types of IMAP
|
||
clients need to release resources associated with the selected
|
||
mailbox without selecting a different mailbox. While IMAP4 provides
|
||
this functionality (via a SELECT command with a nonexistent mailbox
|
||
name or reselecting the same mailbox with EXAMINE command), a more
|
||
clean solution is desirable.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2. UNSELECT command . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 3
|
||
4. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3
|
||
6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
7. Normative References . . . . . . . . . . . . . . . . . . . . . 4
|
||
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 5
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov Standards Track [Page 1]
|
||
|
||
RFC 3691 IMAP UNSELECT command February 2004
|
||
|
||
|
||
1. Introduction
|
||
|
||
Certain types of IMAP clients need to release resources associated
|
||
with the selected mailbox without selecting a different mailbox.
|
||
While [IMAP4] provides this functionality (via a SELECT command with
|
||
a nonexistent mailbox name or reselecting the same mailbox with
|
||
EXAMINE command), a more clean solution is desirable.
|
||
|
||
[IMAP4] defines the CLOSE command that closes the selected mailbox as
|
||
well as permanently removes all messages with the \Deleted flag set.
|
||
|
||
However [IMAP4] lacks a command that simply closes the mailbox
|
||
without expunging it. This document defines the UNSELECT command for
|
||
this purpose.
|
||
|
||
A server which supports this extension indicates this with a
|
||
capability name of "UNSELECT".
|
||
|
||
"C:" and "S:" in examples show lines sent by the client and server
|
||
respectively.
|
||
|
||
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
|
||
this document when typed in uppercase are to be interpreted as
|
||
defined in "Key words for use in RFCs to Indicate Requirement Levels"
|
||
[KEYWORDS].
|
||
|
||
2. UNSELECT Command
|
||
|
||
Arguments: none
|
||
|
||
Responses: no specific responses for this command
|
||
|
||
Result: OK - unselect completed, now in authenticated state
|
||
BAD - no mailbox selected, or argument supplied but
|
||
none permitted
|
||
|
||
The UNSELECT command frees server's resources associated with the
|
||
selected mailbox and returns the server to the authenticated
|
||
state. This command performs the same actions as CLOSE, except
|
||
that no messages are permanently removed from the currently
|
||
selected mailbox.
|
||
|
||
Example: C: A341 UNSELECT
|
||
S: A341 OK Unselect completed
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov Standards Track [Page 2]
|
||
|
||
RFC 3691 IMAP UNSELECT command February 2004
|
||
|
||
|
||
3. Security Considerations
|
||
|
||
It is believed that this extension doesn't raise any additional
|
||
security concerns not already discussed in [IMAP4].
|
||
|
||
4. Formal Syntax
|
||
|
||
The following syntax specification uses the Augmented Backus-Naur
|
||
Form (ABNF) notation as specified in [ABNF]. Non-terminals
|
||
referenced but not defined below are as defined by [IMAP4].
|
||
|
||
Except as noted otherwise, all alphabetic characters are case-
|
||
insensitive. The use of upper or lower case characters to define
|
||
token strings is for editorial clarity only. Implementations MUST
|
||
accept these strings in a case-insensitive fashion.
|
||
|
||
command-select /= "UNSELECT"
|
||
|
||
5. IANA Considerations
|
||
|
||
IMAP4 capabilities are registered by publishing a standards track or
|
||
IESG approved experimental RFC. The registry is currently located
|
||
at:
|
||
|
||
http://www.iana.org/assignments/imap4-capabilities
|
||
|
||
This document defines the UNSELECT IMAP capabilities. IANA has added
|
||
this capability to the registry.
|
||
|
||
6. Acknowledgments
|
||
|
||
UNSELECT command was originally implemented by Tim Showalter in Cyrus
|
||
IMAP server.
|
||
|
||
Also, the author of the document would like to thank Vladimir Butenko
|
||
and Mark Crispin for reminding that UNSELECT has to be documented.
|
||
Also thanks to Simon Josefsson for pointing out that there are
|
||
multiple ways to implement UNSELECT.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov Standards Track [Page 3]
|
||
|
||
RFC 3691 IMAP UNSELECT command February 2004
|
||
|
||
|
||
7. Normative References
|
||
|
||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
|
||
4rev1", RFC 3501, March 2003.
|
||
|
||
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
||
Specifications: ABNF", RFC 2234, November 1997.
|
||
|
||
8. Author's Address
|
||
|
||
Alexey Melnikov
|
||
Isode Limited
|
||
5 Castle Business Village
|
||
Hampton, Middlesex TW12 2BX
|
||
|
||
EMail: Alexey.Melnikov@isode.com
|
||
URI: http://www.melnikov.ca/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov Standards Track [Page 4]
|
||
|
||
RFC 3691 IMAP UNSELECT command February 2004
|
||
|
||
|
||
9. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2004). This document is subject
|
||
to the rights, licenses and restrictions contained in BCP 78 and
|
||
except as set forth therein, the authors retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
|
||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
|
||
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
|
||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed
|
||
to pertain to the implementation or use of the technology
|
||
described in this document or the extent to which any license
|
||
under such rights might or might not be available; nor does it
|
||
represent that it has made any independent effort to identify any
|
||
such rights. Information on the procedures with respect to
|
||
rights in RFC documents can be found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use
|
||
of such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository
|
||
at http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention
|
||
any copyrights, patents or patent applications, or other
|
||
proprietary rights that may cover technology that may be required
|
||
to implement this standard. Please address the information to the
|
||
IETF at ietf-ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Melnikov Standards Track [Page 5]
|
||
|