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]
|
|||
|
|